https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 28 Aug 2017, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 > > --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > Uni-Bielefeld.DE> --- > > --- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- > > On August 25, 2017 4:14:05 PM GMT+02:00, "ro at CeBiTec dot > > Uni-Bielefeld.DE" > [...] > >>My reading is different and corroborates the Solaris ld warnings: > >> > >>* for SHT_NULL, the ELF gABI 4.1 is pretty explicit: > >> > >> p. 4-13, p.57: > >> > >> SHT_NULL > >> > >> This value marks the section header as inactive; it does not > >> have an associated section. Other members of the section > >> header have undefined values. > > > > Yep, exactly as intended. Those sections are removed, their section table > > entry > > is thus inactive. They are not removed from there because changing section > > indices requires rewriting relocation section data. > > I see. There's no way to disable the linker warnings here. We can prune > them in the testsuite if need be, but spilling out tons of warnings > during regular use is ugly. Agreed. As said, "fixing" the symtab issue will require adding code to map old section indices to new ones and re-writing symtab entries (easy) and relocation sections (possible). > >>* SHF_EXCLUDE is a later addition, also included in the Solaris Linker > >> and Libraries Guide: > >> > >> > >>http://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-94076.html#OSLLGchapter6-10675 > >> > >> SHF_EXCLUDE > >> > >> This section is excluded from input to the link-edit of an executable > >> or shared object. This flag is ignored if the SHF_ALLOC flag is also > >> set, or if relocations exist against the section. > > > > Intended. The SHF_ALLOC flag is probably spurious, eventually added by gas? > > Can > > you dump the section header of the affected section? > > Sure: > > Section Header[5]: sh_name: > sh_addr: 0 sh_flags: [ SHF_ALLOC SHF_EXECINSTR > SHF_EXCLUDE ] > sh_size: 0 sh_type: [ SHT_NULL ] > sh_offset: 0x551c sh_entsize: 0 > sh_link: 0 sh_info: 0 > sh_addralign: 0x4 Ok, so it's a deleted section. The following should fix the warning (first hunk is a bugfix): Index: libiberty/simple-object-elf.c =================================================================== --- libiberty/simple-object-elf.c (revision 251375) +++ libiberty/simple-object-elf.c (working copy) @@ -1382,7 +1382,7 @@ simple_object_elf_copy_lto_debug_section unused. That allows the link editor to remove it in a partial link. */ ELF_SET_FIELD (type_functions, ei_class, Shdr, - shdr, sh_type, Elf_Addr, SHT_NULL); + shdr, sh_type, Elf_Word, SHT_NULL); } flags = ELF_FETCH_FIELD (type_functions, ei_class, Shdr, @@ -1390,7 +1390,7 @@ simple_object_elf_copy_lto_debug_section if (ret == 0) flags &= ~SHF_EXCLUDE; else if (ret == -1) - flags |= SHF_EXCLUDE; + flags = SHF_EXCLUDE; ELF_SET_FIELD (type_functions, ei_class, Shdr, shdr, sh_flags, Elf_Addr, flags); } > >>Seems far from clear to me that those are valid ELF objects: the > >>warnings seem totally appropriate. > > > > About the flag mixing probably yes. > > > > Do you have an idea what it segfaults on? OpenSolaris should have the source > > available? > > Not yet. The warnings go back all the way to Solaris 10, however > (without the SHF_EXCLUDE one, although the S10 linker supports the > flag). > > I get the following stacktrace for the SEGV: > > signal SEGV (no mapping at the fault address) in ld32_sym_process at > 0x7fc8c4ca4ddf > 0x00007fc8c4ca4ddf: ld32_sym_process+0x014f: movq > 0x0000000000000010(%rax),%rcx > (dbx) where > =>[1] ld32_sym_process(), at 0x7fc8c4ca4ddf > [2] process_elf(), at 0x7fc8c4c78dae > [3] ld32_process_ifl(), at 0x7fc8c4c795fc > [4] ld32_process_open(), at 0x7fc8c4c79c15 > [5] process_input_file(), at 0x7fc8c4c6e0f2 > [6] process_files_com(), at 0x7fc8c4c6e2e5 > [7] ld32_process_files(), at 0x7fc8c4c6e3bd > [8] ld32_main(), at 0x7fc8c4c715af > [9] main(), at 0x7fc8c5802df0 > > which corresponds to ld_sym_process in > > http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/sgs/libld/common/syms.c#1901 > > The function is way too large to locate the faulting location without > full debug info. > > I'm in contact with the Solaris linker engineers to determine how to > handle this. Thanks. Can you check whether the above patch resolves the extra warning about section flags? The symtab entry one will prevail of course.
