https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #34 from rguenther at suse dot de <rguenther at suse dot de> --- On December 21, 2017 3:30:45 PM GMT+01:00, "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 > >--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec >dot Uni-Bielefeld.DE> --- >I'm having a look at what's still going wrong with Eric's updated >patch. On Solaris/SPARC, there are only two failures left: > >FAIL: g++.dg/lto/pr51567-1 cp_lto_pr51567-1_0.o-cp_lto_pr51567-1_0.o >link, >-flto -g > >output is: >ld: warning: relocation error: R_SPARC_UA32: file >/var/tmp//ccp39Xjadebugobj >section [8].debug_str: invalid offset symbol '.debug_str (section)': >offset >0x2222 >ld: warning: relocation error: R_SPARC_UA32: file >/var/tmp//ccp39Xjadebugobj >section [8].debug_str: invalid offset symbol '.debug_str (section)': >offset >0x2258 > >FAIL: g++.dg/lto/pr53470 cp_lto_pr53470_0.o-cp_lto_pr53470_0.o link, >-g -flto > >for both 32 and 64-bit. Those are only warnings actually, but throw >off >DejaGnu which doesn't expect linker output. > >Investigating what's happending is unnecessarily hard right now because >even with -save-temps, a couple of the intermediate files are removed >and I needed to run the whole compilation under truss to see how they >are created. > >Here's what I found for the g++.dg/lto/pr51567-1 case: > >The linker warning happens during the final link step, which is >(omitting all paths to build directories) > >/usr/ccs/bin/ld -V -M -Y P,/lib:/usr/lib -Qy -o >g++-dg-lto-pr51567-1-01.exe > /usr/lib/crt1.o crtp.o /usr/lib/crti.o /usr/lib/values-Xa.o >/usr/lib/values-xpg6.o crtbegin.o > cck5M.wddebugobj > g++-dg-lto-pr51567-1-01.exe.ltrans0.ltrans.o -lstdc++ -lm > -lrt -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc > crtend.o > /usr/lib/crtn.o > >cck5M.wddebugobj is created in several steps: > >* lto-wrapper cp_lto_pr51567-1_0.o -> ccPhb7tcdebugobjtem > >* ld -r -> cck5M.wddebugobj > >and g++-dg-lto-pr51567-1-01.exe.ltrans0.ltrans.o is from > >/usr/ccs/bin/as -V -Qy -s -xarch=v8plus -m32 -o >g++-dg-lto-pr51567-1-01.exe.ltrans0.ltrans.o >g++-dg-lto-pr51567-1-01.exe.ltrans0.s > >-save-temps preserves the .s file, but not the object. > >The ld warning above occurs (I believe) because the relocation offsets >are wrong: the .debug_str section is only 9 bytes long > >Section Header[5]: sh_name: .debug_str > sh_addr: 0 sh_flags: 0 > sh_size: 0x9 sh_type: [ SHT_PROGBITS ] > sh_offset: 0x5c7 sh_entsize: 0 > sh_link: 0 sh_info: 0 > sh_addralign: 0x1 > >but the offsets are way beyond that. > >Relocation Section: .rela.debug_str > index type offset value addend section symbol >[0] R_SPARC_UA32 0x175 0 0 .debug_str .debug_str (section) >[1] R_SPARC_UA32 0x1ab 0 0 .debug_str .debug_str (section) >[2] R_SPARC_UA32 0x6 0 0 .debug_str .debug_abbrev >(section) > >The genesis of this section is especially strange: > >* In the original object (pre lto-wrapper) there are > >Section Header[5]: sh_name: .gnu.debuglto_.debug_str > sh_addr: 0 sh_flags: 0 > sh_size: 0x9 sh_type: [ SHT_PROGBITS ] > sh_offset: 0x671 sh_entsize: 0 > sh_link: 0 sh_info: 0 > sh_addralign: 0x1 > >Section Header[24]: sh_name: .debug_str > sh_addr: 0 sh_flags: 0 > sh_size: 0x9 sh_type: [ SHT_PROGBITS ] > sh_offset: 0x1466 sh_entsize: 0 > sh_link: 0 sh_info: 0 > sh_addralign: 0x1 > > but no relocs for either section. However I find > >Relocation Section: .rela.gnu.debuglto_.debug_info > index type offset value addend section / symbol > [0] R_SPARC_UA32 0x6 0 0 .gnu.debuglto_.debug_info >.gnu.debuglto_.debug_abbrev (section) > [1] R_SPARC_UA32 0x175 0 0 .gnu.debuglto_.debug_info >.gnu.debuglto_.debug_str (section) > [2] R_SPARC_UA32 0x1ab 0 0 .gnu.debuglto_.debug_info >.gnu.debuglto_.debug_str (section) > >* After the lto-wrapper step, there's only .debug_str left > >Section Header[3]: sh_name: .debug_str > sh_addr: 0 sh_flags: 0 > sh_size: 0x9 sh_type: [ SHT_PROGBITS ] > sh_offset: 0x485 sh_entsize: 0 > sh_link: 0 sh_info: 0 > sh_addralign: 0x1 > > but with the relocs relative to .debug_str > >Relocation Section: .rela.gnu.debuglto_.debug_info > index type offset value addend section symbol >[0] R_SPARC_UA32 0x6 0 0 .debug_str .debug_abbrev >(section) >[1] R_SPARC_UA32 0x175 0 0 .debug_str .debug_str (section) >[2] R_SPARC_UA32 0x1ab 0 0 .debug_str .debug_str (section) > >* After ld -r, there's > >Section Header[5]: sh_name: .debug_str > sh_addr: 0 sh_flags: 0 > sh_size: 0x9 sh_type: [ SHT_PROGBITS ] > sh_offset: 0x5c7 sh_entsize: 0 > sh_link: 0 sh_info: 0 > sh_addralign: 0x1 > >Relocation Section: .rela.debug_str > index type offset value addend section symbol >[0] R_SPARC_UA32 0x175 0 0 .debug_str .debug_str (section) >[1] R_SPARC_UA32 0x1ab 0 0 .debug_str .debug_str (section) >[2] R_SPARC_UA32 0x6 0 0 .debug_str .debug_abbrev >(section) > >Something's very wrong here. For simplicity you might want to elide the partial link step by patching it out of lto-wrapper. Does Solaris / SPARC use the linker plugin? You at least seem to have fat LTO objects around? Both.. Debug_lto. Debug_str and. Debug_str. >On Solaris/x86, there are similar errors, but also a couple of others >I'll be looking at next. > > Rainer
