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

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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.