[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

["ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968

--- Comment #59 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #58 from rguenther at suse dot de <rguenther at suse dot de> ---
> On Thu, 11 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
[...]
>> [I'm continuing this with examples from a build using gas 2.29 instead
>> of as since things are easier to see there.]
>> 
>> While this fixed the error in the group section
>> 
>> Group Section:  .group
>>   Signature Symbol: wm4.0.b58ba986a79b71e96526231091292919
>>   Members:
>>     index   flags / section
>>       [0]   [ COMDAT ]
>>       [1]   .debug_macro
>> 
>> COMDAT group section [    1] `.group' [wm4.0.b58ba986a79b71e96526231091292919]
>> contains 1 sections:
>>    [Index]    Name
>>    [    7]   .debug_macro
>> 
>> the link error (during ld -r) remains:
>
> From Solaris ld?  In both sources to the testcase I only have one

Right: that's the only one I'm regularly testing with.

> COMDAT group -- the above indicates there are two?  In elf.h I see

Oh, sorry, that's just the output of elfdump -g (which showed the
invalid section references before) and readelf -g (which shows the
actual section indices).

> there's a SHT_SUNW_COMDAT - is that used?  That would mean we have to
> remap sections not only in SHT_GROUP but also SHT_SUNW_COMDAT?  Also

Not in the examples I've seen, neither with as nor (expected) with gas.

> web docs suggest that SUN ld might discard one of the two sections
> because it identifies them by name?  This would mean it breaks whatever
> intent we had in producing two .debug_macro (even w/o LTO)?  As said,
> on x86_64 linux I have only one comdat .debug_macro section and the
> other .debug_macro section refers to that via a reloc entry.
>
> So what's the behavior without -flto here if you do a partial link
> of the two input objects?

That works just fine.

>> ld: fatal: relocation error: R_386_32: file /var/tmp//cco6lLmcdebugobjtem:
>> section [6].rel.debug_macro: symbol .debug_macro (section): symbol has been
>> discarded with discarded section: [7].debug_macro
>> 
>> Relocation Section:  .rel.debug_macro
>>   index  type      offset value  section      symbol
>>     [0]  R_386_32     0x3     0  .debug_macro .debug_line (section)
>>     [1]  R_386_32     0x8     0  .debug_macro .debug_macro (section)
>>
>> We do have two .debug_macro sections and their corresponding reloc
>> sections here, as already in the input objects:
>> 
>> Section Header[6]:  sh_name: .rel.debug_macro
>>     sh_addr:      0               sh_flags:   [ SHF_INFO_LINK ]
>>     sh_size:      0x10            sh_type:    [ SHT_REL ]
>>     sh_offset:    0x324           sh_entsize: 0x8 (2 entries)
>>     sh_link:      11              sh_info:    5
>>     sh_addralign: 0x4       
>> 
>> Section Header[8]:  sh_name: .rel.debug_macro
>>     sh_addr:      0               sh_flags:   [ SHF_INFO_LINK ]
>>     sh_size:      0xa50           sh_type:    [ SHT_REL ]
>>     sh_offset:    0xaf4           sh_entsize: 0x8 (330 entries)
>>     sh_link:      11              sh_info:    7
>>     sh_addralign: 0x4       
>> 
>> Section Header[5]:  sh_name: .debug_macro
>>     sh_addr:      0               sh_flags:   0
>>     sh_size:      0x11            sh_type:    [ SHT_PROGBITS ]
>>     sh_offset:    0x312           sh_entsize: 0
>>     sh_link:      0               sh_info:    0
>>     sh_addralign: 0x1       
>> 
>> Section Header[7]:  sh_name: .debug_macro
>>     sh_addr:      0               sh_flags:   [ SHF_GROUP ]
>>     sh_size:      0x7c0           sh_type:    [ SHT_PROGBITS ]
>>     sh_offset:    0x334           sh_entsize: 0
>>     sh_link:      0               sh_info:    0
>>     sh_addralign: 0x1       
>
> Yes, and we preserve both.  I'm not 100% sure what the ld error is about?

Neither am I.  It's probably best to drag the Solaris linker engineers
in to make progress here.

> I do wonder why we have two .debug_macro sections in the first place
> but I haven't investigated if that's on purpose.  At least we have the
> same without -flto.

        Rainer