[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
ro at CeBiTec dot Uni-Bielefeld.DE
gcc-bugzilla@gcc.gnu.org
Wed Jan 3 10:23:00 GMT 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #43 from rguenther at suse dot de <rguenther at suse dot de> ---
> On Tue, 2 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
>>
>> --- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec
>> dot Uni-Bielefeld.DE> ---
>> > --- Comment #41 from rguenther at suse dot de <rguenther at suse dot de> ---
>> [...]
>> >> Unfortunately not: it's really the section index pointing to the
>> >> non-existing (i.e. eliminated) .gnu.debuglto_.debug_info section.
>> >
>> > But that section shouldn't be eliminated :/
>>
>> IIUC it has been renamed to .debug_info:
>>
>> * input object (cp_lto_pr42987_0.o):
>>
>> Section Header[9]: sh_name: .gnu.debuglto_.debug_info
>> sh_addr: 0 sh_flags: 0
>> sh_size: 0x3d4 sh_type: [ SHT_PROGBITS ]
>> sh_offset: 0x7fb sh_entsize: 0
>> sh_link: 0 sh_info: 0
>> sh_addralign: 0x1
>>
>> * output object (ccw3tETddebugobjtem):
>>
>> Section Header[2]: sh_name: .debug_info
>> sh_addr: 0 sh_flags: 0
>> sh_size: 0x3d4 sh_type: [ SHT_PROGBITS ]
>> sh_offset: 0x84d sh_entsize: 0
>> sh_link: 0 sh_info: 0
>> sh_addralign: 0x1
>>
>> without adapting section indices in .symtab.
>
> Yes. It should have retained [9] as section index. Hmmm - you
> have the patch removing sections in your tree? I guess you need
Indeed: without it, Solaris results are far worse.
> to adapt (aka remap) the first_shndx section index I added with
> the patch for the hpux ld issue.
Right: with that change, the .symtab warnings are gone.
>> Besides, there's also a dangling
>>
>> Section Header[6]: sh_name: .rel.gnu.debuglto_.debug_info
>> sh_addr: 0 sh_flags: 0
>> sh_size: 0x8 sh_type: [ SHT_REL ]
>> sh_offset: 0x11c8 sh_entsize: 0x8 (1 entry)
>> sh_link: 5 sh_info: 9
>> sh_addralign: 0x4
>>
>> in the output object.
>
> that should have been used as the reloc section for the new section 2.
> I see sh_info is still 9, it should be 2. That's eventually
> missing handling in the section removal patch.
I'll try to figure this out.
> I've committed the hpux fix so in case you re-base the patch and
> fix up the first_shndx issue please attach the rebased one.
Just did so.
Rainer
More information about the Gcc-bugs
mailing list