[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 #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.

>>* 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       

>>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.

        Rainer