Report LTO phase in lto1 process name v2

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

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.

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

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

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~

> +/* 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.

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

> 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.

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

> 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...

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

> 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

> 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.