| Message ID | yddk4kdurg5.fsf@manam.CeBiTec.Uni-Bielefeld.DE |
|---|---|
| State | New |
| Headers | show |
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
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
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
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 >
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})