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
