[PATCH] [PATCH] Report LTO phase in lto1 process name v2

[PATCH] [PATCH] Report LTO phase in lto1 process name v2

[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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Diego Novillo]

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.

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Andrew Pinski]

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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Andi Kleen]

  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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Richard Henderson]

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~

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[DJ Delorie]

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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Andi Kleen]

  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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[DJ Delorie]

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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Andi Kleen]

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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[DJ Delorie]

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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Ryan Mansfield]

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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[DJ Delorie]

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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Andi Kleen]

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.

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Andi Kleen]

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.

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Ryan Mansfield]

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

RE: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[green]

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.

RE: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Andi Kleen]

 > 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

Re: [PATCH] [PATCH] Report LTO phase in lto1 process name v2

[Anthony Green]

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