Patchwork [lto,doc] Use nm -png in collect2 on Solaris 2

login
register
mail settings
Submitter Rainer Orth
Date Nov. 16, 2010, 5:08 p.m.
Message ID <yddk4kdurg5.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
Download mbox | patch
Permalink /patch/71435/
State New
Headers show

Comments

Rainer Orth - Nov. 16, 2010, 5:08 p.m.
Prompted by two reports in private mail, I've started investigating why
I was seeing far fewer LTO failures on sparc-sun-solaris2.10 than they
did.  I've found that the problem was caused by the way collect2 looks
for LTO markers (__gnu_lto_v1) in the object files linked and calls lto1
if found:

* collect2 expects the output format produced by GNU nm -n and silently
  fails (i.e. doesn't find the markers and thus doesn't call lto1) if
  the format is different.  This happens when Solaris nm is used, which
  produces the System V format by default.  I've filed

  lto/46502	collect2 LTO marker detection is fragile wrt. to nm output format

  for this.

* Besides, collect2 doesn't hardcode the version nm used, but does a
  runtime search, first for gnm, then for nm, and some other variations
  thereof.  This is again quite fragile, since whether or not LTO works
  depends on the user's PATH.  I believe nm should be handled like as
  and ld in this respect, i.e. determined at configure time and
  hardcode.  There's

  lto/46503	collect2's search for nm makes LTO support fragile

  for this issue.

To work around this issue for the moment, I've used the patch below.  It
turns out that NM_FLAGS can be set as required to yield the required nm
output format, and nm -png works on Solaris 2 both with Sun nm and GNU
nm.

Unfortunately, this macro wasn't even documented so far, so I've added a
short description.

Bootstrapped on i386-pc-solaris2.11 without regressions (as expected,
gnm was already used here), on i386-pc-solaris2.10 where it caused one
regression

+FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -flto -flto-partition=1to1

where lto1 hadn't been run before, but fixed two other failures:

-FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute -O3 -flto -flto-partition=1to1
-FAIL: gcc.dg/lto/ipareference2 c_lto_ipareference2_0.o-c_lto_ipareference2_1.o execute  -O1 -flto -flto-partition=1to1 -fwhole-program

and on sparc-sun-solaris2.10 where it exposed 181 regressions.  Eric
already described the issue in

	http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00642.html

but got no reply whatsoever.

Would it be acceptable to deal with this in libiberty/simple-object-elf.c
(simple_object_elf_attributes_compare) the same way it was done in
gcc/lto/lto-elf.c (is_compatible_architecture) before, i.e. upgrade
attrs1->machine to EM_SPARC32PLUS if a v8plus object file is added?

It would be good to have this breakage fixed soon, given that is has
existed for almost two weeks since the introduction of the
simple_object_* functions.

While I don't need approval for the config/sol2.h part of the patch
below, I do for the documentation part.

Ok for mainline?

	Rainer


2010-11-13  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* config/sol2.h (NM_FLAGS): Define.
	* doc/tm.texi.in (Macros for Initialization, NM_FLAGS): Document.
	* doc/tm.texi: Update.
Ian Taylor - Nov. 16, 2010, 5:55 p.m.
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> 2010-11-13  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
>
> 	* config/sol2.h (NM_FLAGS): Define.
> 	* doc/tm.texi.in (Macros for Initialization, NM_FLAGS): Document.
> 	* doc/tm.texi: Update.

This is OK.

Thanks.

Ian
Rainer Orth - Nov. 16, 2010, 6:07 p.m.
Ian Lance Taylor <iant@google.com> writes:

> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>
>> 2010-11-13  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
>>
>> 	* config/sol2.h (NM_FLAGS): Define.
>> 	* doc/tm.texi.in (Macros for Initialization, NM_FLAGS): Document.
>> 	* doc/tm.texi: Update.
>
> This is OK.

Installed, thanks.

Any suggestions on how to deal with the EM_SPARC vs. EM_SPARC32PLUS
problem caused by the switch to the simple_object_* interfaces?  Do you
think my suggestion in the patch submission is reasonable?

	Rainer
Dave Korn - Nov. 16, 2010, 7:47 p.m.
On 16/11/2010 17:08, Rainer Orth wrote:
> and on sparc-sun-solaris2.10 where it exposed 181 regressions.  Eric
> already described the issue in
> 
> 	http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00642.html
> 
> but got no reply whatsoever.

  Sorry Eric, I saw and have kept your email aside, but wanted to finish
dealing with PR462690 before I replied.

> Would it be acceptable to deal with this in libiberty/simple-object-elf.c
> (simple_object_elf_attributes_compare) the same way it was done in
> gcc/lto/lto-elf.c (is_compatible_architecture) before, i.e. upgrade
> attrs1->machine to EM_SPARC32PLUS if a v8plus object file is added?

  Yes, I think adding the machine info to the attributes is the best solution,
it was certainly what I planned to try doing.

> It would be good to have this breakage fixed soon, given that is has
> existed for almost two weeks since the introduction of the
> simple_object_* functions.

  Again, sorry; not forgotten but I should have said I'd put it on my to-do
list.  It was a matter of getting major features in during stage 1 so that we
could fix any bugs arising during stage 3...

  Shall I leave it with you, or would you like me to go and have a bash at it?
 I'm not a SPARC expert but if you pointed me at a testcase I could go use the
cfarm machines to test a patch.

    cheers,
      DaveK
Richard Guenther - Nov. 17, 2010, 10:42 a.m.
On Tue, Nov 16, 2010 at 8:47 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 16/11/2010 17:08, Rainer Orth wrote:
>> and on sparc-sun-solaris2.10 where it exposed 181 regressions.  Eric
>> already described the issue in
>>
>>       http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00642.html
>>
>> but got no reply whatsoever.
>
>  Sorry Eric, I saw and have kept your email aside, but wanted to finish
> dealing with PR462690 before I replied.
>
>> Would it be acceptable to deal with this in libiberty/simple-object-elf.c
>> (simple_object_elf_attributes_compare) the same way it was done in
>> gcc/lto/lto-elf.c (is_compatible_architecture) before, i.e. upgrade
>> attrs1->machine to EM_SPARC32PLUS if a v8plus object file is added?
>
>  Yes, I think adding the machine info to the attributes is the best solution,
> it was certainly what I planned to try doing.

Btw, I thought about removing this __gnu_lto_v1 special symbol as it
causes problems elsewhere (PR43542 for example).  With simple-object
we should be able to just check for the presence of one of the standard
LTO section names, for example .gnu.lto_.opts which is one that is
not mangled for partial linking.

So, it would be really nice to get rid of the special symbol.

Richard.

>> It would be good to have this breakage fixed soon, given that is has
>> existed for almost two weeks since the introduction of the
>> simple_object_* functions.
>
>  Again, sorry; not forgotten but I should have said I'd put it on my to-do
> list.  It was a matter of getting major features in during stage 1 so that we
> could fix any bugs arising during stage 3...
>
>  Shall I leave it with you, or would you like me to go and have a bash at it?
>  I'm not a SPARC expert but if you pointed me at a testcase I could go use the
> cfarm machines to test a patch.
>
>    cheers,
>      DaveK
>

Patch

diff -r a21d3cbbf27e gcc/config/sol2.h
--- a/gcc/config/sol2.h	Sat Nov 13 16:03:04 2010 +0100
+++ b/gcc/config/sol2.h	Sun Nov 14 23:13:43 2010 +0100
@@ -195,6 +195,10 @@ 
 #undef SUPPORTS_INIT_PRIORITY
 #define SUPPORTS_INIT_PRIORITY 0
 
+/* collect2.c can only parse GNU nm -n output.  Solaris nm needs -png to
+   produce the same format.  */
+#define NM_FLAGS "-png"
+
 #define STDC_0_IN_SYSTEM_HEADERS 1
 
 /*
diff -r a21d3cbbf27e gcc/doc/tm.texi.in
--- a/gcc/doc/tm.texi.in	Sat Nov 13 16:03:04 2010 +0100
+++ b/gcc/doc/tm.texi.in	Sun Nov 14 23:13:43 2010 +0100
@@ -8397,16 +8397,24 @@ 
 Define this macro as a C string constant containing the file name to use
 to execute @command{nm}.  The default is to search the path normally for
 @command{nm}.
+@end defmac
+
+@defmac NM_FLAGS
+@command{collect2} calls @command{nm} to scan object files for static
+constructors and destructors and LTO info.  By default, @option{-n} is
+passed.  Define @code{NM_FLAGS} to a C string constant if other options
+are needed to get the same output formut as GNU @command{nm -n}
+produces.
+@end defmac
 
 If your system supports shared libraries and has a program to list the
 dynamic dependencies of a given library or executable, you can define
 these macros to enable support for running initialization and
 termination functions in shared libraries:
-@end defmac
 
 @defmac LDD_SUFFIX
 Define this macro to a C string constant containing the name of the program
-which lists dynamic dependencies, like @command{"ldd"} under SunOS 4.
+which lists dynamic dependencies, like @command{ldd} under SunOS 4.
 @end defmac
 
 @defmac PARSE_LDD_OUTPUT (@var{ptr})