https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 18 Sep 2017, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 > > --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > Uni-Bielefeld.DE> --- > > --- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> --- > [...] > >>That worked just fine, thanks. > >> > >>While there are still ld warnings > >> > >>ld: warning: file /var/tmp//ccmgPmhadebugobjtem: section [2] has > >>invalid type [ > >>SHT_NULL ] > >> > >>ro@lucy 87 > elfdump -c -I 2 cc2qd7lbdebugobjtem > >>cc2qd7lbdebugobjtem: : invalid sh_type: 0 > >> > >>Section Header[2]: sh_name: > >> sh_addr: 0 sh_flags: [ SHF_EXCLUDE ] > >> sh_size: 0 sh_type: [ SHT_NULL ] > >> sh_offset: 0x4980 sh_entsize: 0 > >> sh_link: 0 sh_info: 0 > >> sh_addralign: 0x10 > >> > >>and there's no way to silence them from the ld command line, I should > >>be > >>able to prune them for the testsuite at least. > > > > Can you report this issue to the Solaris folks? > > I'd already done so upon the first early lto debug failures. The ld > SEGV for a symtab referencing an non-string table is already fixed > upstream, but it's unclear when this will be generally available and > older versions (especially Solaris 10) will almost certainly remain > unfixed. > > > However, the final link > >>fails: > >> > >>Undefined first referenced > >> symbol in file > >>__gnu_lto_v1 /var/tmp//ccQylLjddebugobj > >> > >>It turns out that __gnu_lto_v1 in the original object > >> > >>[336] 0x1 0x1 OBJT GLOB D 0 COMMON > >>__gnu_lto_v1 > >> > >>remains in the one produced by lto-wrapper: > >> > >> [339] 0 0 NOTY GLOB D 0 UNDEF __gnu_lto_v1 > >> > >>Need to check what's going on here... > > > > How does it fail? The symbol should be unused... > > With the link failure due to undefined __gnu_lto_v1 cited above. I'd > argue that ld behaves exactly as expected: it tries to resolve the > undefined symbols, cannot find a definition, and stops. Hmm, but the symbol isn't used anywhere (in a relocation)? > I've had some success with the attached patch, which discards symbols by > marking them weak. On top of that, right now I need to prune tons of ld > warnings like > > ld: warning: file /var/tmp//ccv3Kl9adebugobjtem: section [1] has invalid type > [ > SHT_NULL ] > > (already mentioned) and It would be nice to have an opinion on why this is invalid. And a suggested workaround. > ld: warning: file /var/tmp//ccv3Kl9adebugobjtem: section [34].symtab: > symbol[2]: > global symbol has no name I thought I fixed those. What symbols end up with their name stripped? > Pruning the messages is a hack to see how we stand, but certainly not an > option for production use. Sure. As mentioned we could go full length and re-write all relocation sections and with that compress both the symbol table and the section header table. Maybe for compressing the section header table rewriting the symbol table is enough?
