public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* RE: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
@ 2010-11-18 21:33 green
  2010-11-18 23:46 ` Andi Kleen
  0 siblings, 1 reply; 19+ messages in thread
From: green @ 2010-11-18 21:33 UTC (permalink / raw)
  To: Andi Kleen; +Cc: rmansfield, gcc-patches, ak, DJ Delorie

Andi,

You shouldn't be using link tests universally in libiberty either.  Many
newlib based targets can't build executables at this point in the
toolchain build.

If you look earlier in configure.ac you'll see...

  # We are being configured as a target library.  AC_REPLACE_FUNCS
  # may not work correctly, because the compiler may not be able to
  # link executables.  Note that we may still be being configured
  # native.

At a minimum you should wrap all this with a test for with_newlib = no.

The moxie-elf toolchain doesn't build right now because of this.

Thanks,

AG



(sorry for the top-posting.  I'm temporarily using a broken client)

-------- Original Message --------
Subject: Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
From: Andi Kleen <andi@firstfloor.org>
Date: Thu, October 07, 2010 2:32 am
To: DJ Delorie <dj@redhat.com>
Cc: rmansfield@qnx.com, gcc-patches@gcc.gnu.org, ak@linux.intel.com

Andi Kleen <andi@firstfloor.org> writes:
>
> Subject: [PATCH] Turn PR_SET_NAME check into link check
>
> Fixes cross compilation for libiberty after my change

Committed as obvious now.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-11-18 21:33 [PATCH] [PATCH] Report LTO phase in lto1 process name v2 green
@ 2010-11-18 23:46 ` Andi Kleen
  2010-11-19  9:15   ` Anthony Green
  0 siblings, 1 reply; 19+ messages in thread
From: Andi Kleen @ 2010-11-18 23:46 UTC (permalink / raw)
  To: green; +Cc: Andi Kleen, rmansfield, gcc-patches, ak, DJ Delorie

 > You shouldn't be using link tests universally in libiberty either.  Many
> newlib based targets can't build executables at this point in the
> toolchain build.
>
> If you look earlier in configure.ac you'll see...
>
>   # We are being configured as a target library.  AC_REPLACE_FUNCS
>   # may not work correctly, because the compiler may not be able to
>   # link executables.  Note that we may still be being configured
>   # native.
>
> At a minimum you should wrap all this with a test for with_newlib = no.
>
> The moxie-elf toolchain doesn't build right now because of this.

How does it fail? In theory you should just not get
process name support.

-Andi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-11-18 23:46 ` Andi Kleen
@ 2010-11-19  9:15   ` Anthony Green
  0 siblings, 0 replies; 19+ messages in thread
From: Anthony Green @ 2010-11-19  9:15 UTC (permalink / raw)
  To: Andi Kleen; +Cc: rmansfield, gcc-patches, ak, DJ Delorie

On 11/18/2010 5:41 PM, Andi Kleen wrote:
>   >  You shouldn't be using link tests universally in libiberty either.  Many
>> newlib based targets can't build executables at this point in the
>> toolchain build.
>>
>> If you look earlier in configure.ac you'll see...
>>
>>    # We are being configured as a target library.  AC_REPLACE_FUNCS
>>    # may not work correctly, because the compiler may not be able to
>>    # link executables.  Note that we may still be being configured
>>    # native.
>>
>> At a minimum you should wrap all this with a test for with_newlib = no.
>>
>> The moxie-elf toolchain doesn't build right now because of this.
>
> How does it fail? In theory you should just not get
> process name support.

The configure script exits with "Link tests are not allowed after 
GCC_NO_EXECUTABLES.".

AG

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-07  7:23       ` Andi Kleen
  2010-10-07  9:32         ` Andi Kleen
@ 2010-10-07 10:03         ` Ryan Mansfield
  1 sibling, 0 replies; 19+ messages in thread
From: Ryan Mansfield @ 2010-10-07 10:03 UTC (permalink / raw)
  To: Andi Kleen; +Cc: DJ Delorie, gcc-patches, ak

On 10-10-07 03:22 AM, Andi Kleen wrote:
> On Thu, Oct 07, 2010 at 02:40:20AM -0400, DJ Delorie wrote:
>>
>>> Can someone with more autoconf experience please suggest a way
>>> to fix this?
>>
>> Try a link test instead of a run test.
>>
>> Note that the cross compile check will also check for cross-building a
>> native.
>
> Ok that seems to work here.  Ryan, can you please confirm that the patch fixes
> your problem?

That patch fixes things for me. Thanks.

Regards,

Ryan Mansfield

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-07  7:23       ` Andi Kleen
@ 2010-10-07  9:32         ` Andi Kleen
  2010-10-07 10:03         ` Ryan Mansfield
  1 sibling, 0 replies; 19+ messages in thread
From: Andi Kleen @ 2010-10-07  9:32 UTC (permalink / raw)
  To: DJ Delorie; +Cc: rmansfield, gcc-patches, ak

Andi Kleen <andi@firstfloor.org> writes:
>
> Subject: [PATCH] Turn PR_SET_NAME check into link check
>
> Fixes cross compilation for libiberty after my change

Committed as obvious now.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-07  6:40     ` DJ Delorie
@ 2010-10-07  7:23       ` Andi Kleen
  2010-10-07  9:32         ` Andi Kleen
  2010-10-07 10:03         ` Ryan Mansfield
  0 siblings, 2 replies; 19+ messages in thread
From: Andi Kleen @ 2010-10-07  7:23 UTC (permalink / raw)
  To: DJ Delorie; +Cc: Andi Kleen, rmansfield, gcc-patches, ak

On Thu, Oct 07, 2010 at 02:40:20AM -0400, DJ Delorie wrote:
> 
> > Can someone with more autoconf experience please suggest a way
> > to fix this?
> 
> Try a link test instead of a run test.
> 
> Note that the cross compile check will also check for cross-building a
> native.

Ok that seems to work here.  Ryan, can you please confirm that the patch fixes 
your problem?

Thanks,

-Andi


Subject: [PATCH] Turn PR_SET_NAME check into link check

Fixes cross compilation for libiberty after my change

libiberty/

2010-10-07  Andi Kleen <ak@linux.intel.com>

	* configure: Regenerate.
	* configure.ac: Turn PR_SET_NAME check into link check.

diff --git a/libiberty/configure b/libiberty/configure
index 7ff7792..7579000 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -5707,13 +5707,10 @@ fi
 
 
 # check for prctl PR_SET_NAME
-if test "$cross_compiling" = yes; then :
-  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
-$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
-as_fn_error "cannot run test program while cross compiling
-See \`config.log' for more details." "$LINENO" 5; }
-else
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+if test x$gcc_no_link = xyes; then
+  as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5
+fi
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
 #include <sys/prctl.h>
@@ -5723,15 +5720,13 @@ int main()
 }
 
 _ACEOF
-if ac_fn_c_try_run "$LINENO"; then :
+if ac_fn_c_try_link "$LINENO"; then :
 
 $as_echo "#define HAVE_PRCTL_SET_NAME 1" >>confdefs.h
 
 fi
-rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
-  conftest.$ac_objext conftest.beam conftest.$ac_ext
-fi
-
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
 
 case "${host}" in
   *-*-cygwin* | *-*-mingw*)
diff --git a/libiberty/configure.ac b/libiberty/configure.ac
index 8b7be18..73ea6c9 100644
--- a/libiberty/configure.ac
+++ b/libiberty/configure.ac
@@ -536,7 +536,7 @@ AC_SUBST(CHECK)
 AC_SUBST(target_header_dir)
 
 # check for prctl PR_SET_NAME
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #include <sys/prctl.h>
 int main()
 {

-- 
ak@linux.intel.com -- Speaking for myself only.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-07  6:32   ` Andi Kleen
@ 2010-10-07  6:40     ` DJ Delorie
  2010-10-07  7:23       ` Andi Kleen
  0 siblings, 1 reply; 19+ messages in thread
From: DJ Delorie @ 2010-10-07  6:40 UTC (permalink / raw)
  To: Andi Kleen; +Cc: rmansfield, andi, gcc-patches, ak


> Can someone with more autoconf experience please suggest a way
> to fix this?

Try a link test instead of a run test.

Note that the cross compile check will also check for cross-building a
native.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-07  3:17 ` Ryan Mansfield
@ 2010-10-07  6:32   ` Andi Kleen
  2010-10-07  6:40     ` DJ Delorie
  0 siblings, 1 reply; 19+ messages in thread
From: Andi Kleen @ 2010-10-07  6:32 UTC (permalink / raw)
  To: Ryan Mansfield; +Cc: Andi Kleen, gcc-patches, Andi Kleen

> I can no longer cross compile libiberty after this patch:
> 
> configure: error: in `/home/ryan/gnu/gcc/trunk/arm-eabi/arm-unknown-linux-gnueabi/libiberty':
> configure: error: cannot run test program while cross compiling
> See `config.log' for more details.
> make[1]: *** [configure-target-libiberty] Error 1
> make[1]: Leaving directory `/home/ryan/gnu/gcc/trunk/arm-eabi'
> make: *** [all] Error 2

Thanks for the report.

I'm not sure how to solve this. I tried checking for
cross_compiling = no, but that seems to be set even on my 
plain x86_64-linux box, presumably for the multilibs.

Can someone with more autoconf experience please suggest a way
to fix this?

This is really for the host anyways, so doesn't need to be built
on the target (I'm not sure what libiberty is needed for on the 
target anyways)

Thanks,
-Andi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-06 15:49 Andi Kleen
                   ` (2 preceding siblings ...)
  2010-10-06 17:49 ` DJ Delorie
@ 2010-10-07  3:17 ` Ryan Mansfield
  2010-10-07  6:32   ` Andi Kleen
  3 siblings, 1 reply; 19+ messages in thread
From: Ryan Mansfield @ 2010-10-07  3:17 UTC (permalink / raw)
  To: Andi Kleen; +Cc: gcc-patches, Andi Kleen

On 10-10-06 11:49 AM, Andi Kleen wrote:
> From: Andi Kleen<ak@linux.intel.com>
>
> On larger parallel WHOPR builds I find it useful to see in top which
> phase a given lto1 is in.
>
> Set the process name to lto1-wpa, lto1-ltrans, lto1-lto depending
> on the current mode.
>
> This is currently only implemented for Linux and only
> using the "comm" process name, which is reported in top.
>
> v2: Moved function to libiberty, renamed setproctitle to match
> BSD. In theory it should pick up BSD's libc function for this
> on a BSD system, but I haven't tested this.
>
> Passes bootstrap and testsuite on x86_64-linux. Ok to commit?

>   AC_SUBST(CHECK)
>   AC_SUBST(target_header_dir)
>
> +# check for prctl PR_SET_NAME
> +AC_RUN_IFELSE([AC_LANG_SOURCE([[
> +#include<sys/prctl.h>
> +int main()
> +{
> +  return (prctl(PR_SET_NAME, "foo") == 0) ? 0 : 1;
> +}
> +]])], AC_DEFINE(HAVE_PRCTL_SET_NAME, 1,
> +	[Define if you have prctl PR_SET_NAME]))
> +

I can no longer cross compile libiberty after this patch:

configure: error: in 
`/home/ryan/gnu/gcc/trunk/arm-eabi/arm-unknown-linux-gnueabi/libiberty':
configure: error: cannot run test program while cross compiling
See `config.log' for more details.
make[1]: *** [configure-target-libiberty] Error 1
make[1]: Leaving directory `/home/ryan/gnu/gcc/trunk/arm-eabi'
make: *** [all] Error 2

libiberty/configure now has:

# check for prctl PR_SET_NAME
if test "$cross_compiling" = yes; then :
   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
as_fn_error "cannot run test program while cross compiling
See \`config.log' for more details." "$LINENO" 5; }
else

Regards,

Ryan Mansfield

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-06 21:41       ` Andi Kleen
@ 2010-10-06 22:07         ` DJ Delorie
  0 siblings, 0 replies; 19+ messages in thread
From: DJ Delorie @ 2010-10-06 22:07 UTC (permalink / raw)
  To: Andi Kleen; +Cc: andi, gcc-patches


> I thought I had regenerated the dependencies and it created
> that makefile rule automatically, or did I miss a step?

I just said to make sure it was done...

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-06 20:06     ` DJ Delorie
@ 2010-10-06 21:41       ` Andi Kleen
  2010-10-06 22:07         ` DJ Delorie
  0 siblings, 1 reply; 19+ messages in thread
From: Andi Kleen @ 2010-10-06 21:41 UTC (permalink / raw)
  To: DJ Delorie; +Cc: andi, gcc-patches

On Wed, Oct 06, 2010 at 04:06:33PM -0400, DJ Delorie wrote:
> 
> > That was intentional; the idea was that it fall back to the BSD libc
> > version like the other libiberty fallback functions (that was one of
> > the feedbacks for v1)
> 
> Ah, ok.
> 
> I'm OK with the libiberty parts then, as long as you add inline
> documentation to setproctitle.c and regenerate the docs and make sure

Thanks will fix that.

> the dependencies don't need to be regenerated.

I thought I had regenerated the dependencies and it created
that makefile rule automatically, or did I miss a step?

-Andi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-06 17:51   ` Andi Kleen
@ 2010-10-06 20:06     ` DJ Delorie
  2010-10-06 21:41       ` Andi Kleen
  0 siblings, 1 reply; 19+ messages in thread
From: DJ Delorie @ 2010-10-06 20:06 UTC (permalink / raw)
  To: Andi Kleen; +Cc: andi, gcc-patches


> That was intentional; the idea was that it fall back to the BSD libc
> version like the other libiberty fallback functions (that was one of
> the feedbacks for v1)

Ah, ok.

I'm OK with the libiberty parts then, as long as you add inline
documentation to setproctitle.c and regenerate the docs and make sure
the dependencies don't need to be regenerated.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-06 17:49 ` DJ Delorie
@ 2010-10-06 17:51   ` Andi Kleen
  2010-10-06 20:06     ` DJ Delorie
  0 siblings, 1 reply; 19+ messages in thread
From: Andi Kleen @ 2010-10-06 17:51 UTC (permalink / raw)
  To: DJ Delorie; +Cc: Andi Kleen, gcc-patches

  On 10/6/2010 7:48 PM, DJ Delorie wrote:
>> +/* Set the title of a process */
>> +extern void setproctitle (const char *name, ...);
> Do we really want to add another global namespace-colliding name here?
> We've used l_* before, how about l_setproctitle() ?

That was intentional; the idea was that it fall back to the BSD libc 
version like
the other libiberty fallback functions (that was one of the feedbacks 
for v1)


>> -/* Define to 1 if you have the declaration of `basename', and to 0 if you
>> -   don't. */
>> +/* Define to 1 if you have the declaration of `basename(char *)', and to 0 if
>> +   you don't. */
>>   #undef HAVE_DECL_BASENAME
> Please double-check that you're using the right versions of all the
> tools to regenerate these with.

I believe I do, but the file was stale that is why I got these 
additional changes.

-Andi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-06 15:49 Andi Kleen
  2010-10-06 15:51 ` Diego Novillo
  2010-10-06 17:32 ` Andrew Pinski
@ 2010-10-06 17:49 ` DJ Delorie
  2010-10-06 17:51   ` Andi Kleen
  2010-10-07  3:17 ` Ryan Mansfield
  3 siblings, 1 reply; 19+ messages in thread
From: DJ Delorie @ 2010-10-06 17:49 UTC (permalink / raw)
  To: Andi Kleen; +Cc: gcc-patches, ak


> +/* Set the title of a process */
> +extern void setproctitle (const char *name, ...);

Do we really want to add another global namespace-colliding name here?
We've used l_* before, how about l_setproctitle() ?

> -/* Define to 1 if you have the declaration of `basename', and to 0 if you
> -   don't. */
> +/* Define to 1 if you have the declaration of `basename(char *)', and to 0 if
> +   you don't. */
>  #undef HAVE_DECL_BASENAME

Please double-check that you're using the right versions of all the
tools to regenerate these with.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-06 17:42   ` Andi Kleen
@ 2010-10-06 17:47     ` Richard Henderson
  0 siblings, 0 replies; 19+ messages in thread
From: Richard Henderson @ 2010-10-06 17:47 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Andrew Pinski, Andi Kleen, gcc-patches

On 10/06/2010 10:42 AM, Andi Kleen wrote:
> v1 of the code used that,  but I wasn't sure if that is available in libiberty and I
> changed it to the void cast. If it is I can change it to that before comitting.

ATTRIBUTE_UNUSED is in ansidecl.h, available to libiberty.


r~

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-06 17:32 ` Andrew Pinski
@ 2010-10-06 17:42   ` Andi Kleen
  2010-10-06 17:47     ` Richard Henderson
  0 siblings, 1 reply; 19+ messages in thread
From: Andi Kleen @ 2010-10-06 17:42 UTC (permalink / raw)
  To: Andrew Pinski; +Cc: Andi Kleen, gcc-patches

  On 10/6/2010 7:31 PM, Andrew Pinski wrote:
> On Wed, Oct 6, 2010 at 8:49 AM, Andi Kleen<andi@firstfloor.org>  wrote:
>
>> +void
>> +setproctitle (const char *name, ...)
>> +{
>> +  (void) name;
>> +
>> +#ifdef HAVE_PRCTL_SET_NAME
>> +  /* On Linux this sets the top visible "comm", but not necessarily
>> +     the name visible in ps. */
>> +  prctl (PR_SET_NAME, name);
>> +#endif
>> +}
> Why not use ATTRIBUTE_UNUSED instead of "(void)name;" ?  I also don't
> like this idea really because it causes some folks not to understand
> what the actual executable it is.

v1 of the code used that,  but I wasn't sure if that is available in 
libiberty and I
changed it to the void cast. If it is I can change it to that before 
comitting.

-Andi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-06 15:49 Andi Kleen
  2010-10-06 15:51 ` Diego Novillo
@ 2010-10-06 17:32 ` Andrew Pinski
  2010-10-06 17:42   ` Andi Kleen
  2010-10-06 17:49 ` DJ Delorie
  2010-10-07  3:17 ` Ryan Mansfield
  3 siblings, 1 reply; 19+ messages in thread
From: Andrew Pinski @ 2010-10-06 17:32 UTC (permalink / raw)
  To: Andi Kleen; +Cc: gcc-patches, Andi Kleen

On Wed, Oct 6, 2010 at 8:49 AM, Andi Kleen <andi@firstfloor.org> wrote:

> +void
> +setproctitle (const char *name, ...)
> +{
> +  (void) name;
> +
> +#ifdef HAVE_PRCTL_SET_NAME
> +  /* On Linux this sets the top visible "comm", but not necessarily
> +     the name visible in ps. */
> +  prctl (PR_SET_NAME, name);
> +#endif
> +}

Why not use ATTRIBUTE_UNUSED instead of "(void)name;" ?  I also don't
like this idea really because it causes some folks not to understand
what the actual executable it is.

Thanks,
Andrew Pinski

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2
  2010-10-06 15:49 Andi Kleen
@ 2010-10-06 15:51 ` Diego Novillo
  2010-10-06 17:32 ` Andrew Pinski
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 19+ messages in thread
From: Diego Novillo @ 2010-10-06 15:51 UTC (permalink / raw)
  To: Andi Kleen; +Cc: gcc-patches, Andi Kleen

On Wed, Oct 6, 2010 at 15:49, Andi Kleen <andi@firstfloor.org> wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> On larger parallel WHOPR builds I find it useful to see in top which
> phase a given lto1 is in.
>
> Set the process name to lto1-wpa, lto1-ltrans, lto1-lto depending
> on the current mode.
>
> This is currently only implemented for Linux and only
> using the "comm" process name, which is reported in top.
>
> v2: Moved function to libiberty, renamed setproctitle to match
> BSD. In theory it should pick up BSD's libc function for this
> on a BSD system, but I haven't tested this.
>
> Passes bootstrap and testsuite on x86_64-linux. Ok to commit?
>
> gcc/lto/
>
> 2010-10-05  Andi Kleen <ak@linux.intel.com>
>
>        * lto.c (lto_process_name): Add.
>        (lto_main): Call lto_process_name.

The LTO parts are OK.


Diego.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH] [PATCH] Report LTO phase in lto1 process name v2
@ 2010-10-06 15:49 Andi Kleen
  2010-10-06 15:51 ` Diego Novillo
                   ` (3 more replies)
  0 siblings, 4 replies; 19+ messages in thread
From: Andi Kleen @ 2010-10-06 15:49 UTC (permalink / raw)
  To: gcc-patches; +Cc: Andi Kleen

From: Andi Kleen <ak@linux.intel.com>

On larger parallel WHOPR builds I find it useful to see in top which
phase a given lto1 is in.

Set the process name to lto1-wpa, lto1-ltrans, lto1-lto depending
on the current mode.

This is currently only implemented for Linux and only
using the "comm" process name, which is reported in top.

v2: Moved function to libiberty, renamed setproctitle to match
BSD. In theory it should pick up BSD's libc function for this
on a BSD system, but I haven't tested this.

Passes bootstrap and testsuite on x86_64-linux. Ok to commit?

gcc/lto/

2010-10-05  Andi Kleen <ak@linux.intel.com>

	* lto.c (lto_process_name): Add.
	(lto_main): Call lto_process_name.

include/

2010-10-05  Andi Kleen <ak@linux.intel.com>

	* libiberty.h (setproctitle): Add prototype.

libiberty/

2010-10-05  Andi Kleen <ak@linux.intel.com>

	* Makefile.in (CFILES): Add setproctitle.
	(CONFIGURED_OFILES): Add setproctitle.
	(setproctitle): Add rule.
	* config.in: Regenerate.
	* configure: Regenerate.
	* configure.ac: Add checks for prctl PR_SET_NAME and setproctitle.
	* setproctitle.c: Add file.
---
 gcc/lto/lto.c            |   14 ++++++++++++++
 include/libiberty.h      |    3 +++
 libiberty/Makefile.in    |   13 +++++++++++--
 libiberty/config.in      |   16 ++++++++--------
 libiberty/configure      |   31 ++++++++++++++++++++++++++++++-
 libiberty/configure.ac   |   14 +++++++++++++-
 libiberty/setproctitle.c |   41 +++++++++++++++++++++++++++++++++++++++++
 7 files changed, 120 insertions(+), 12 deletions(-)
 create mode 100644 libiberty/setproctitle.c

diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 323b09a..9c7423c 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -2377,6 +2377,18 @@ lto_eh_personality (void)
   return lto_eh_personality_decl;
 }
 
+/* Set the process name based on the LTO mode. */
+
+static void 
+lto_process_name (void)
+{
+  if (flag_lto)
+    setproctitle ("lto1-lto");
+  if (flag_wpa)
+    setproctitle ("lto1-wpa");
+  if (flag_ltrans)
+    setproctitle ("lto1-ltrans");
+}
 
 /* Main entry point for the GIMPLE front end.  This front end has
    three main personalities:
@@ -2401,6 +2413,8 @@ lto_eh_personality (void)
 void
 lto_main (int debug_p ATTRIBUTE_UNUSED)
 {
+  lto_process_name ();
+
   lto_init_reader ();
 
   /* Read all the symbols and call graph from all the files in the
diff --git a/include/libiberty.h b/include/libiberty.h
index b320b18..f54ca18 100644
--- a/include/libiberty.h
+++ b/include/libiberty.h
@@ -634,6 +634,9 @@ extern int vsnprintf (char *, size_t, const char *, va_list) ATTRIBUTE_PRINTF(3,
 extern int strverscmp (const char *, const char *);
 #endif
 
+/* Set the title of a process */
+extern void setproctitle (const char *name, ...);
+
 #define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0]))
 
 /* Drastically simplified alloca configurator.  If we're using GCC,
diff --git a/libiberty/Makefile.in b/libiberty/Makefile.in
index c5e9929..1893254 100644
--- a/libiberty/Makefile.in
+++ b/libiberty/Makefile.in
@@ -144,7 +144,8 @@ CFILES = alloca.c argv.c asprintf.c atexit.c				\
 	 pex-unix.c pex-win32.c						\
          physmem.c putenv.c						\
 	random.c regex.c rename.c rindex.c				\
-	safe-ctype.c setenv.c sha1.c sigsetmask.c snprintf.c sort.c	\
+	safe-ctype.c setenv.c setproctitle.c sha1.c sigsetmask.c        \
+         snprintf.c sort.c						\
 	 spaces.c splay-tree.c stpcpy.c stpncpy.c strcasecmp.c		\
 	 strchr.c strdup.c strerror.c strncasecmp.c strncmp.c		\
 	 strrchr.c strsignal.c strstr.c strtod.c strtol.c strtoul.c	\
@@ -201,7 +202,9 @@ CONFIGURED_OFILES = ./asprintf.$(objext) ./atexit.$(objext)		\
 	 ./pex-unix.$(objext) ./pex-win32.$(objext)			\
 	 ./putenv.$(objext)						\
 	./random.$(objext) ./rename.$(objext) ./rindex.$(objext)	\
-	./setenv.$(objext) ./sigsetmask.$(objext) ./snprintf.$(objext)	\
+	./setenv.$(objext) 						\
+	 ./setproctitle.$(objext)					\
+	 ./sigsetmask.$(objext) ./snprintf.$(objext)			\
 	 ./stpcpy.$(objext) ./stpncpy.$(objext) ./strcasecmp.$(objext)	\
 	 ./strchr.$(objext) ./strdup.$(objext) ./strncasecmp.$(objext)	\
 	 ./strncmp.$(objext) ./strndup.$(objext) ./strrchr.$(objext)	\
@@ -944,6 +947,12 @@ $(CONFIGURED_OFILES): stamp-picdir
 	else true; fi
 	$(COMPILE.c) $(srcdir)/setenv.c $(OUTPUT_OPTION)
 
+./setproctitle.$(objext): $(srcdir)/setproctitle.c config.h $(INCDIR)/ansidecl.h
+	if [ x"$(PICFLAG)" != x ]; then \
+	  $(COMPILE.c) $(PICFLAG) $(srcdir)/setproctitle.c -o pic/$@; \
+	else true; fi
+	$(COMPILE.c) $(srcdir)/setproctitle.c $(OUTPUT_OPTION)
+
 ./sha1.$(objext): $(srcdir)/sha1.c config.h $(INCDIR)/ansidecl.h $(INCDIR)/sha1.h
 	if [ x"$(PICFLAG)" != x ]; then \
 	  $(COMPILE.c) $(PICFLAG) $(srcdir)/sha1.c -o pic/$@; \
diff --git a/libiberty/config.in b/libiberty/config.in
index 1931648..02d93da 100644
--- a/libiberty/config.in
+++ b/libiberty/config.in
@@ -44,8 +44,8 @@
    don't. */
 #undef HAVE_DECL_ASPRINTF
 
-/* Define to 1 if you have the declaration of `basename', and to 0 if you
-   don't. */
+/* Define to 1 if you have the declaration of `basename(char *)', and to 0 if
+   you don't. */
 #undef HAVE_DECL_BASENAME
 
 /* Define to 1 if you have the declaration of `calloc', and to 0 if you don't.
@@ -154,9 +154,6 @@
 /* Define to 1 if you have the <memory.h> header file. */
 #undef HAVE_MEMORY_H
 
-/* Define to 1 if you have the `mempcpy' function. */
-#undef HAVE_MEMPCPY
-
 /* Define to 1 if you have the `memset' function. */
 #undef HAVE_MEMSET
 
@@ -169,6 +166,9 @@
 /* Define to 1 if you have the `on_exit' function. */
 #undef HAVE_ON_EXIT
 
+/* Define if you have prctl PR_SET_NAME */
+#undef HAVE_PRCTL_SET_NAME
+
 /* Define to 1 if you have the `psignal' function. */
 #undef HAVE_PSIGNAL
 
@@ -199,6 +199,9 @@
 /* Define to 1 if you have the `setenv' function. */
 #undef HAVE_SETENV
 
+/* Define to 1 if you have the `setproctitle' function. */
+#undef HAVE_SETPROCTITLE
+
 /* Define to 1 if you have the `sigsetmask' function. */
 #undef HAVE_SIGSETMASK
 
@@ -358,9 +361,6 @@
 /* Define to 1 if you have the `vprintf' function. */
 #undef HAVE_VPRINTF
 
-/* Define to 1 if you have the `vsnprintf' function. */
-#undef HAVE_VSNPRINTF
-
 /* Define to 1 if you have the `vsprintf' function. */
 #undef HAVE_VSPRINTF
 
diff --git a/libiberty/configure b/libiberty/configure
index 9a3b2d3..7ff7792 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -5276,6 +5276,7 @@ funcs="$funcs vprintf"
 funcs="$funcs vsnprintf"
 funcs="$funcs vsprintf"
 funcs="$funcs waitpid"
+funcs="$funcs setproctitle"
 
 # Also in the old function.def file: alloca, vfork, getopt.
 
@@ -5298,7 +5299,8 @@ if test "x" = "y"; then
     on_exit \
     psignal pstat_getdynamic pstat_getstatic putenv \
     random realpath rename rindex \
-    sbrk setenv sigsetmask snprintf stpcpy stpncpy strcasecmp strchr strdup \
+    sbrk setenv setproctitle sigsetmask snprintf stpcpy stpncpy strcasecmp strchr \
+    strdup \
      strerror strncasecmp strndup strrchr strsignal strstr strtod strtol \
      strtoul strverscmp sysconf sysctl sysmp \
     table times tmpnam \
@@ -5704,6 +5706,33 @@ fi
 
 
 
+# check for prctl PR_SET_NAME
+if test "$cross_compiling" = yes; then :
+  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error "cannot run test program while cross compiling
+See \`config.log' for more details." "$LINENO" 5; }
+else
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+#include <sys/prctl.h>
+int main()
+{
+  return (prctl(PR_SET_NAME, "foo") == 0) ? 0 : 1;
+}
+
+_ACEOF
+if ac_fn_c_try_run "$LINENO"; then :
+
+$as_echo "#define HAVE_PRCTL_SET_NAME 1" >>confdefs.h
+
+fi
+rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
+  conftest.$ac_objext conftest.beam conftest.$ac_ext
+fi
+
+
 case "${host}" in
   *-*-cygwin* | *-*-mingw*)
     $as_echo "#define HAVE_SYS_ERRLIST 1" >>confdefs.h
diff --git a/libiberty/configure.ac b/libiberty/configure.ac
index 4de83f9..8b7be18 100644
--- a/libiberty/configure.ac
+++ b/libiberty/configure.ac
@@ -351,6 +351,7 @@ funcs="$funcs vprintf"
 funcs="$funcs vsnprintf"
 funcs="$funcs vsprintf"
 funcs="$funcs waitpid"
+funcs="$funcs setproctitle"
 
 # Also in the old function.def file: alloca, vfork, getopt.
 
@@ -373,7 +374,8 @@ if test "x" = "y"; then
     on_exit \
     psignal pstat_getdynamic pstat_getstatic putenv \
     random realpath rename rindex \
-    sbrk setenv sigsetmask snprintf stpcpy stpncpy strcasecmp strchr strdup \
+    sbrk setenv setproctitle sigsetmask snprintf stpcpy stpncpy strcasecmp strchr \
+    strdup \
      strerror strncasecmp strndup strrchr strsignal strstr strtod strtol \
      strtoul strverscmp sysconf sysctl sysmp \
     table times tmpnam \
@@ -533,6 +535,16 @@ fi
 AC_SUBST(CHECK)
 AC_SUBST(target_header_dir)
 
+# check for prctl PR_SET_NAME
+AC_RUN_IFELSE([AC_LANG_SOURCE([[
+#include <sys/prctl.h>
+int main()
+{
+  return (prctl(PR_SET_NAME, "foo") == 0) ? 0 : 1;
+}
+]])], AC_DEFINE(HAVE_PRCTL_SET_NAME, 1,
+	[Define if you have prctl PR_SET_NAME]))
+
 case "${host}" in
   *-*-cygwin* | *-*-mingw*)
     AC_DEFINE(HAVE_SYS_ERRLIST)
diff --git a/libiberty/setproctitle.c b/libiberty/setproctitle.c
new file mode 100644
index 0000000..0003af4
--- /dev/null
+++ b/libiberty/setproctitle.c
@@ -0,0 +1,41 @@
+/* Set the title of a process.
+   Copyright (C) 2010 Free Software Foundation, Inc.
+
+This file is part of the libiberty library.
+Libiberty is free software; you can redistribute it and/or
+modify it under the terms of the GNU Library General Public
+License as published by the Free Software Foundation; either
+version 2 of the License, or (at your option) any later version.
+
+Libiberty is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+Library General Public License for more details.
+
+You should have received a copy of the GNU Library General Public
+License along with libiberty; see the file COPYING.LIB.  If not,
+write to the Free Software Foundation, Inc., 51 Franklin Street - Fifth Floor,
+Boston, MA 02110-1301, USA.  */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+#ifdef HAVE_PRCTL_SET_NAME
+#include <sys/prctl.h>
+#endif
+#include "ansidecl.h"
+
+/* Set the title of a process to NAME. va args not supported for now,
+   but defined for compatibility with BSD. */
+
+void
+setproctitle (const char *name, ...)
+{
+  (void) name;
+
+#ifdef HAVE_PRCTL_SET_NAME
+  /* On Linux this sets the top visible "comm", but not necessarily
+     the name visible in ps. */
+  prctl (PR_SET_NAME, name);
+#endif
+}
-- 
1.7.1

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2010-11-19  4:02 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-18 21:33 [PATCH] [PATCH] Report LTO phase in lto1 process name v2 green
2010-11-18 23:46 ` Andi Kleen
2010-11-19  9:15   ` Anthony Green
  -- strict thread matches above, loose matches on Subject: below --
2010-10-06 15:49 Andi Kleen
2010-10-06 15:51 ` Diego Novillo
2010-10-06 17:32 ` Andrew Pinski
2010-10-06 17:42   ` Andi Kleen
2010-10-06 17:47     ` Richard Henderson
2010-10-06 17:49 ` DJ Delorie
2010-10-06 17:51   ` Andi Kleen
2010-10-06 20:06     ` DJ Delorie
2010-10-06 21:41       ` Andi Kleen
2010-10-06 22:07         ` DJ Delorie
2010-10-07  3:17 ` Ryan Mansfield
2010-10-07  6:32   ` Andi Kleen
2010-10-07  6:40     ` DJ Delorie
2010-10-07  7:23       ` Andi Kleen
2010-10-07  9:32         ` Andi Kleen
2010-10-07 10:03         ` Ryan Mansfield

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).