https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- 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: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 > > --- Comment #57 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > Uni-Bielefeld.DE> --- > > --- Comment #56 from rguenther at suse dot de <rguenther at suse dot de> --- > > On Wed, 10 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > [...] > > I can reproduce that with -ffat-lto-objects where indeed we somehow > > get confused when we should preserve only part of a SHT_GROUP given > > we don't "prune" groups. The question to me is why do we put > > both macro sections in a single group ... but that's probably > > an artifact on how things are supposed to work in the end... > > [I wonder if SHF_EXCLUDE works "properly" for group members when > > doing a non-LTO link] > > > > Anyway, this should be "easy" to fix with sth like > > > > else if (sh_type == SHT_GROUP) > > { > > /* Remap section indices in groups and remove removed members. > > */ > > unsigned char *ent, *dst; > > for (dst = ent = buf + 4; ent < buf + length - 4; ent += 4) ^^^ typo here, should be ent < buf + length > > { > > unsigned shndx = type_functions->fetch_Elf_Word (ent); > > if (pfnret[shndx - 1] == -1) > > ; > > else > > { > > type_functions->set_Elf_Word (dst, sh_map[shndx]); > > dst += 4; > > } > > } > > /* Adjust the length. */ > > length = dst - buf; > > } > > > > in the group handling. > > > > That fixes -ffat-lto-objects handling for me with the testcase. > > Will re-test with that. > > [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 COMDAT group -- the above indicates there are two? In elf.h I see 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 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? > 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? 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.
