Copy x86_64 _mcount.op from _mcount.o

  No need to compile x86_64 _mcount.S with -pg.  We can just copy the
normal static object.

	* gmon/Makefile (noprof): Add $(sysdep_noprof).
	* sysdeps/x86_64/Makefile (sysdep_noprof): Add _mcount.
---
 gmon/Makefile           | 2 +-
 sysdeps/x86_64/Makefile | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
  

On Thu, Mar 3, 2016 at 5:45 AM, H.J. Lu <hongjiu.lu@intel.com> wrote:
> No need to compile x86_64 _mcount.S with -pg.  We can just copy the
> normal static object.
>
>         * gmon/Makefile (noprof): Add $(sysdep_noprof).
>         * sysdeps/x86_64/Makefile (sysdep_noprof): Add _mcount.
> ---
>  gmon/Makefile           | 2 +-
>  sysdeps/x86_64/Makefile | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gmon/Makefile b/gmon/Makefile
> index abb96d7..c7c9e58 100644
> --- a/gmon/Makefile
> +++ b/gmon/Makefile
> @@ -45,7 +45,7 @@ include ../Rules
>  # On systems where `profil' is not a system call, the same
>  # problem exists for the internal functions in profil.c.
>
> -noprof := mcount
> +noprof := mcount $(sysdep_noprof)
>  ifeq (,$(filter profil,$(unix-syscalls)))
>  noprof += profil sprofil
>  endif
> diff --git a/sysdeps/x86_64/Makefile b/sysdeps/x86_64/Makefile
> index 67ed5ba..9fcadd8 100644
> --- a/sysdeps/x86_64/Makefile
> +++ b/sysdeps/x86_64/Makefile
> @@ -7,6 +7,7 @@ endif
>
>  ifeq ($(subdir),gmon)
>  sysdep_routines += _mcount
> +sysdep_noprof += _mcount
>  endif
>
>  ifeq ($(subdir),malloc)
> --
> 2.5.0
>

There is no difference in gmon/_mcount.op before and after
my patch.  I will check it in shortly.
  

I don't understand why you thought this was a change that should go in
immediately without review.

No change that introduces a new variable to the protocol between generic
makefiles and sysdeps/.../Makefile fragments should go in without review.

This is not at all in the "obvious enough" category, so I really don't
see any justification for committing it without waiting a normal amount
of time for normal review.

The burden is always on you to justify why normal review can be skipped.
I should not need to give you reasons why it should not have been skipped.

If I'd had a chance to review this change, I'd have said that I don't see
any adequate rationale for this change.  You said it was a no-op change, so
clearly it was not actually needed for anything.  I don't think the trivial
amount of build time added by assembling one small file is anywhere near
adequate to justify the maintenance burden of a fiddly makefile change like
this.
  

On Thu, Mar 3, 2016 at 4:10 PM, Roland McGrath <roland@hack.frob.com> wrote:

> If I'd had a chance to review this change, I'd have said that I don't see
> any adequate rationale for this change.

It's a pre-condition for using ENTRY/END here:
https://sourceware.org/ml/libc-alpha/2016-03/msg00055.html
  

> On Thu, Mar 3, 2016 at 4:10 PM, Roland McGrath <roland@hack.frob.com> wrote:
> 
> > If I'd had a chance to review this change, I'd have said that I don't see
> > any adequate rationale for this change.
> 
> It's a pre-condition for using ENTRY/END here:
> https://sourceware.org/ml/libc-alpha/2016-03/msg00055.html

That needs to be said in the patch posting, and in comments in the makefile.