Trying to build current gcc mainline with GNU ld 2.19 fails linking the 64-bit libstdc++.so. When I retried with binutils mainline, the problems persists: % /vol/gcc/obj/binutils-2.19.50-g/ld/ld-new -V -G -dy -z text -m elf64_sparc -Y P,/usr/lib/sparcv9 -rpath-link /usr/lib/sparcv9 -Qy -o .libs/libstdc++.so.6.0.11 -L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src -L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src/.libs -L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src -L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/sparc-sun-solaris2.11/sparcv9/libstdc++-v3/src/.libs -L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9 -L/usr/ccs/lib/sparcv9 -L/lib/sparcv9 -L/usr/lib/sparcv9 -L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc -L/usr/ccs/lib -L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9 -L/usr/ccs/lib/sparcv9 -L/lib/sparcv9 -L/usr/lib/sparcv9 -L/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc -L/usr/ccs/lib /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crti.o /usr/ccs/lib/sparcv9/values-Xa.o /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crtbegin.o .libs/atomic.o .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/functexcept.o .libs/hash.o .libs/hash_c++0x.o .libs/globals_io.o .libs/hashtable.o .libs/hashtable_c++0x.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/limits_c++0x.o .libs/list.o .libs/debug_list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/system_error.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/mutex.o .libs/condition_variable.o .libs/chrono.o .libs/thread.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o .libs/parallel_list.o .libs/parallel_settings.o --whole-archive ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a --no-whole-archive -lm -lgcc_s /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crtend.o /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/sparcv9/crtn.o -O1 -z relro --gc-sections --version-script=libstdc++-symbols.ver -soname libstdc++.so.6 GNU ld (GNU Binutils) 2.19.50.20081111 Supported emulations: elf32_sparc elf64_sparc .libs/atomic.o: could not read symbols: Bad value Tracking this down (with an unoptimize ld compiled with -g only, because gdb couldn't proper handle the -g -O2 binary), I found that bfd_set_error (bfd_error_bad_value) is called from here: #0 bfd_set_error (error_tag=bfd_error_bad_value) at /vol/gnu/src/binutils/binutils-dist/bfd/bfd.c:425 #1 0x0008d130 in _bfd_sparc_elf_check_relocs (abfd=0x1dc510, info=0x19d978, sec=0x1f6a20, relocs=0x1fdc10) at /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:1335 #2 0x000c4210 in elf_link_add_object_symbols (abfd=0x1dc510, info=0x19d978) at /vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:4722 #3 0x000c4dc8 in bfd_elf_link_add_symbols (abfd=0x1dc510, info=0x19d978) at /vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:5044 #4 0x0002e604 in load_symbols (entry=0x19dfc8, place=0xffbfe8d0) at /vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:2599 #5 0x0002f6b8 in open_input_bfds (s=0x19dfc8, force=0) at /vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:3028 #6 0x00037798 in lang_process () at /vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:6112 #7 0x0003ce4c in main (argc=114, argv=0xffbfea7c) at /vol/gnu/src/binutils/binutils-dist/ld/ldmain.c:453 I.e. from bfd/elfxx-sparc.c (_bfd_sparc_elf_check_relocs), l. 1335. At that point, r_type = 18 (R_SPARC_WPLT30) and readelf on the problematic object file reveals % readelf -r .libs/atomic.o |grep R_SPARC_WPLT30 000000000014 000e00000012 R_SPARC_WPLT30 0000000000000000 .text + 0 000000000008 001800000012 R_SPARC_WPLT30 0000000000000000 atomic_flag_clear_expl + 0 000000000008 001b00000012 R_SPARC_WPLT30 0000000000000000 atomic_flag_test_and_s + 0 000000000008 001b00000012 R_SPARC_WPLT30 0000000000000000 atomic_flag_test_and_s + 0 It seems that a workaround similar to the ! ABI_64_P() case may be needed for the 64-bit case as well.
Created attachment 3062 [details] Guess at how to handle local WPLT30 relocations for 64-bit sparc.
Hi Rainer, I am not familiar with the Sparc architecture, but I have uploaded a possible patch which might fix the problem you discovered. Please could you try it out and let me know if it really works ? Cheers Nick
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Nick, > I am not familiar with the Sparc architecture, but I have uploaded a possible me, neither, I just happen to test regularly on Solaris :-) > patch which might fix the problem you discovered. Please could you try it out > and let me know if it really works ? Unfortunately, it doesn't: + /* The Solaris native assembler will generate a WPLT30 + reloc for a local symbol if you assemble a call from + one section to another when using -K pic. We treat + it as WDISP30. */ + if ((! ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT32) + || (ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT64)) + goto r_sparc_plt32; The ABI_64_P() part doesn't trigger since ELF32_R_TYPE (rel->r_info) is 18 (i.e. R_SPARC_WPLT30) at this point. I don't really have an idea why/if the 32-bit part works. I suppose it was added back in 1994 by Ian: Fri Oct 21 17:13:07 1994 Ian Lance Taylor <ian@sanguine.cygnus.com> [...] * elf32-sparc.c (elf_sparc_howto_table): Fix R_SPARC_PC22 by [...] (elf32_sparc_relocate_section): For a GOT reloc against a global symbol when no dynamic object was seen, initialize the contents of the .got section. For a GOT reloc against a local symbol, only create a R_SPARC_RELATIVE reloc when generating a shared object. Treat a R_SPARC_WPLT30 reloc against a symbol for which we did not create a PLT entry as a R_SPARC_WDISP30 reloc. but the mainling list archive on www.sourceware.org doesn't go that far back. Perhaps he can shed some light on this. Rainer
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Rainer, > + if ((! ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT32) > + || (ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT64)) > The ABI_64_P() part doesn't trigger since ELF32_R_TYPE (rel->r_info) is 18 > (i.e. R_SPARC_WPLT30) at this point. I don't really have an idea why/if > the 32-bit part works. As a matter of interest if you change this to: if ((! ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT32) || (ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_WPLT30)) does the patch then work ? (I agree that the 32-bit case does seem rather mysterious). Cheers Nick
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Nick, > As a matter of interest if you change this to: > > if ((! ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_PLT32) > || (ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) == R_SPARC_WPLT30)) > > does the patch then work ? (I agree that the 32-bit case does seem > rather mysterious). unfortunately not: this time ld SEGVs: /vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: warning: section `.bss' type changed to PROGBITS /vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2765 Segmentation Fault #0 0x00091024 in _bfd_sparc_elf_relocate_section (output_bfd=0x1c5f10, info=0x19da08, input_bfd=0x1dc5a0, input_section=0x1f6ab0, contents=0x1082948 "\235ã¿@\20560\002\003", relocs=0x1fdca0, local_syms=0x753920, local_sections=0xfa3c98) at /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2768 #1 0x000d4b9c in elf_link_input_bfd (finfo=0xffbfe880, input_bfd=0x1dc5a0) at /vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:9327 #2 0x000d7f84 in bfd_elf_final_link (abfd=0x1c5f10, info=0x19da08) at /vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:10452 #3 0x00040958 in ldwrite () at /vol/gnu/src/binutils/binutils-dist/ld/ldwrite.c:567 #4 0x0003cec0 in main (argc=114, argv=0xffbfea7c) at /vol/gnu/src/binutils/binutils-dist/ld/ldmain.c:462 At l. 2768 of elfxx-sparc.c (_bfd_sparc_elf_relocate_section), h is NULL, so if (h->plt.offset == (bfd_vma) -1 || htab->splt == NULL) { /* We didn't make a PLT entry for this symbol. This happens when statically linking PIC code, or when using -Bsymbolic. */ break; } crashes when dereferencing it. If I adapt the check immediately before @@ -2751,19 +2751,12 @@ /* Relocation is to the entry for this symbol in the procedure linkage table. */ - if (! ABI_64_P (output_bfd)) - { - /* The Solaris native assembler will generate a WPLT30 reloc - for a local symbol if you assemble a call from one - section to another when using -K pic. We treat it as - WDISP30. */ - if (h == NULL) - break; - } - else - { - BFD_ASSERT (h != NULL); - } + /* The Solaris native assembler will generate a WPLT30 reloc + for a local symbol if you assemble a call from one + section to another when using -K pic. We treat it as + WDISP30. */ + if (h == NULL) + break; if (h->plt.offset == (bfd_vma) -1 || htab->splt == NULL) { I still get the "section `.bss' type changed to PROGBITS" warning, but at least a libstdc++.so is produced. I'm now continuting the GCC bootstrap and will run the testsuite see if this seems to work. Rainer
I didn't write the code in question. The code I added was simple: if there is a R_SPARC_WPLT30 reloc against a symbol for which no PLT entry was created, we handle it as a R_SPARC_WDISP30 reloc. That is straightforward and obviously correct. It is correct whether the object file is 32-bit or 64-bit. I haven't looked at the 64-bit SPARC ELF format, and I'm not sure what all the relocs in that case are. But it seems clear that if (h == NULL && ELFXX_R_TYPE (rel->r_info) == R_SPARC_WPLT30)) _bfd_sparc_elf_check_relocs should simply return TRUE. The same case must also be handled in _bfd_sparc_elf_relocate_section.
Created attachment 3065 [details] Another patch attempt
Hi Rainer, OK taking Ian's comments into account I have uploaded another attempt at a patch for this problem. Please could you try it out and let me know if it is any good ? Cheers Nick
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Nick, > OK taking Ian's comments into account I have uploaded another attempt at a > patch for this problem. Please could you try it out and let me know if it is > any good ? unfortunately, ld SEGVs now here: #0 0x0008d19c in _bfd_sparc_elf_check_relocs (abfd=0x1dc518, info=0x19d980, sec=0x1f6a28, relocs=0x1fdc18) at /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:1348 #1 0x000c4214 in elf_link_add_object_symbols (abfd=0x1dc518, info=0x19d980) at /vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:4722 #2 0x000c4dcc in bfd_elf_link_add_symbols (abfd=0x1dc518, info=0x19d980) at /vol/gnu/src/binutils/binutils-dist/bfd/elflink.c:5044 #3 0x0002e604 in load_symbols (entry=0x19dfd0, place=0xffbfe8d0) at /vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:2599 #4 0x0002f6b8 in open_input_bfds (s=0x19dfd0, force=0) at /vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:3028 #5 0x00037798 in lang_process () at /vol/gnu/src/binutils/binutils-dist/ld/ldlang.c:6112 #6 0x0003ce4c in main (argc=114, argv=0xffbfea7c) at /vol/gnu/src/binutils/binutils-dist/ld/ldmain.c:453 On l.1348 of elfxx-sparc.c (_bfd_sparc_elf_check_relocs), h is NULL. Rainer
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Rainer, > unfortunately, ld SEGVs now here: > > #0 0x0008d19c in _bfd_sparc_elf_check_relocs (abfd=0x1dc518, info=0x19d980, sec=0x1f6a28, relocs=0x1fdc18) at /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:1348 Doh. Thinko in the patch. Please change: case R_SPARC_WPLT30: /* The Solaris native assembler will generate a WPLT30 reloc for a local symbol if you assemble a call from one section to another when using -K pic. We treat it as WDISP30. */ break; to: case R_SPARC_WPLT30: /* The Solaris native assembler will generate a WPLT30 reloc for a local symbol if you assemble a call from one section to another when using -K pic. We treat it as WDISP30. */ return TRUE; (Only the last line has changed). Cheers Nick
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Nick, > (Only the last line has changed). done, but not much better either: at first I get a lot of assertion failures GNU ld (GNU Binutils) 2.19.50.20081111 Supported emulations: elf32_sparc elf64_sparc /vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: warning: section `.bss' type changed to PROGBITS /vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2701 /vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2701 /vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2701 /vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2701 /vol/gccsrc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2664 [1838 assertion failures total ...] Program received signal SIGSEGV, Segmentation fault. 0x00090d60 in _bfd_sparc_elf_relocate_section (output_bfd=0x1c5ea0, info=0x19d998, input_bfd=0x391be8, input_section=0x3b80c0, contents=0x1080538 "\235ã¿@\222\020", relocs=0x3c62d8, local_syms=0xc69be8, local_sections=0xa08fb0) at /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2703 (gdb) p local_got_offsets $1 = (bfd_vma *) 0x0 Rainer
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Rainer, > done, but not much better either: at first I get a lot of assertion > failures Ok, this is going nowhere. Is it possible for you to create a small testcase that reproduces the problem ? Say just a single object file that you try to link ? If so then please can you upload it to the issue along with a description of the linker command line used and I will try to reproduce the problem locally. Cheers Nick
Created attachment 3068 [details] problematic object file
Created attachment 3069 [details] object file that shows both the original and new problems
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Nick, > Ok, this is going nowhere. Is it possible for you to create a small > testcase that reproduces the problem ? Say just a single object file > that you try to link ? If so then please can you upload it to the issue > along with a description of the linker command line used and I will try > to reproduce the problem locally. I've just uploaded badval.o. If I try to link it into a shared library with % ld -G -m elf64_sparc -o badval.so badval.o using the original gld 2.19, I get badval.o: could not read symbols: Bad value With ld patched with the latest elfxx-sparc.c, I get /vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: BFD (GNU Binutils) 2.19.50.20081111 assertion fail /vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:2701 Segmentation Fault Rainer
Created attachment 3072 [details] third try
Hi Rainer, OK, I have uploaded a third patch for you to try. This one works(1) for me although to be honest I do not really see how it is different from the second patch. Anyway give it a whirl and see how you go. Cheers Nick (1) Where "works" means that the linker does not complain and a binary is produced. I cannot tell you if the binary is actually functional.
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Nick, > OK, I have uploaded a third patch for you to try. This one works(1) for me > although to be honest I do not really see how it is different from the second > patch. Anyway give it a whirl and see how you go. > > Cheers > Nick > > (1) Where "works" means that the linker does not complain and a binary is > produced. I cannot tell you if the binary is actually functional. this one looks quite good: I can now successfully link the 64-bit libstdc++.so. Unfortunately, regtesting the resulting GCC build is currently hampered by the following warning: /vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: warning: section `.bss' type changed to PROGBITS This is harmless during the build, but many testcases (not only c++ and libstdc++-v3) fail due to the unexpected message. Thanks. Rainer
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Rainer, > Unfortunately, regtesting the resulting GCC build is > currently hampered by the following warning: > > /vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: warning: section `.bss' type changed to PROGBITS > > This is harmless during the build, but many testcases (not only c++ and > libstdc++-v3) fail due to the unexpected message. I think that this is a separate problem, rather than fallout from the patch. Nevertheless it would be good to track it down. Can you create a small testcase that reproduces it ? Cheers Nick
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Nick, > I think that this is a separate problem, rather than fallout from the certainly. > patch. Nevertheless it would be good to track it down. Can you create > a small testcase that reproduces it ? I'll try. First of all, I need to understand what the warning is all about. Rainer
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Rainer, > I'll try. First of all, I need to understand what the warning is all > about. Oh, well the "progbits" attribute indicates that the section contains data values, but the .bss section should in theory be completely empty and just initialized with zero bytes when the program is loaded into memory. (ie its type should be NOBITS). What is probably happening is that one or more of your input object files has a .bss section with the wrong attributes. Why that should be is currently a mystery, but first we need to locate those object files (or else demonstrate that the problem has some other cause). Cheers Nick
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Nick, > Oh, well the "progbits" attribute indicates that the section contains > data values, but the .bss section should in theory be completely empty > and just initialized with zero bytes when the program is loaded into > memory. (ie its type should be NOBITS). ok, understood. > What is probably happening is that one or more of your input object > files has a .bss section with the wrong attributes. Why that should be > is currently a mystery, but first we need to locate those object files > (or else demonstrate that the problem has some other cause). Every single one of the libstdc++ object files is affected. E.g. % readelf -S --wide .libs/wstring-inst.o |grep -A1 '\.bss' [191] .bss._ZZL18__gthread_active_pvE21__gthread_active_once PROGBITS 0000000000000000 0205a8 000020 00 WA 0 0 8 [192] .data._ZZL18__gthread_active_pvE22__gthread_active_mutex PROGBITS 0000000000000000 0205c8 000018 00 WA 0 0 8 Looking at the assembler source, I find: .section ".bss._ZZL18__gthread_active_pvE21__gthread_active_once",#alloc,#write .align 8 .type _ZZL18__gthread_active_pvE21__gthread_active_once, #object .size _ZZL18__gthread_active_pvE21__gthread_active_once, 32 _ZZL18__gthread_active_pvE21__gthread_active_once: .skip 32 If I assemble the same source file with gas 2.19, I get [ 3] .bss NOBITS 00000000 00003c 000000 00 WA 0 0 1 [338] .bss._ZZL18__gthread_active_pvE21__gthread_active_once NOBITS 00000000 01a988 000020 00 WA 0 0 8 Rainer
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Rainer, > Every single one of the libstdc++ object files is affected. E.g. > > % readelf -S --wide .libs/wstring-inst.o |grep -A1 '\.bss' > [191] .bss._ZZL18__gthread_active_pvE21__gthread_active_once PROGBITS 0000000000000000 0205a8 000020 00 WA 0 0 8 > If I assemble the same source file with gas 2.19, I get > > [ 3] .bss NOBITS 00000000 00003c 000000 00 WA 0 0 1 > [338] .bss._ZZL18__gthread_active_pvE21__gthread_active_once NOBITS 00000000 01a988 000020 00 WA 0 0 8 So, are you saying that assembling with gas v2.19 fixes the problem ? If so, can we close the PR (and apply the patch) ? Cheers Nick
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Nick, > So, are you saying that assembling with gas v2.19 fixes the problem ? indeed: either it's a Sun as bug or gcc makes an assumption not borne out by documentation (but held by gas). I'm still trying to determine which it is. > If so, can we close the PR (and apply the patch) ? Sure, thanks alot for your help. Rainer
Hi Rainer, OK - I have checked in the patch along with this changelog entry. Cheers Nick bfd/ChangeLog PR 7027 * elfxx-sparc.c (_bfd_sparc_elf_check_relocs): Treat WPLT30 relocs against local symbols in 64-bit binaries as if they were WDISP30 relocs. (_bfd_sparc_elf_relocate_section): Likewise.
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not read symbols: Bad value Hi Nick, > OK - I have checked in the patch along with this changelog entry. great, thanks a lot for all your help. Rainer