https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 
Uni-Bielefeld.DE> ---
> --- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
[...]
>> Why does Solaris ld output warnings by default?  Does it have an
>> option to suppress them?  It doesn't seem that it considers them
>> errors?
>
> Btw, I suppose I can simply leave the names of the global UNDEFs in place.
> That'll remove that specific warning.  Still the question is why solaris
> ld segfaults and whether there is a way to supress the section warning
> by doing some magic to the entry.

It seems the ld SEGV happens because the string table associated with
the symtab is size 0 and not of type SHT_STRTAB:

Section Header[171]:  sh_name: .symtab
    sh_addr:      0               sh_flags:   [ SHF_ALLOC ]
    sh_size:      0x14c0          sh_type:    [ SHT_SYMTAB ]
    sh_offset:    0x551c          sh_entsize: 0x10 (332 entries)
    sh_link:      172             sh_info:    325
    sh_addralign: 0x4       

Section Header[172]:  sh_name: 
    sh_addr:      0               sh_flags:   [ SHF_EXCLUDE ]
    sh_size:      0               sh_type:    [ SHT_NULL ]
    sh_offset:    0x69dc          sh_entsize: 0
    sh_link:      0               sh_info:    0

The input object has

Section Header[171]:  sh_name: .symtab
    sh_addr:      0               sh_flags:   [ SHF_ALLOC ]
    sh_size:      0x14c0          sh_type:    [ SHT_SYMTAB ]
    sh_offset:    0x3e13c         sh_entsize: 0x10 (332 entries)
    sh_link:      172             sh_info:    325
    sh_addralign: 0x4       

Section Header[172]:  sh_name: .strtab
    sh_addr:      0               sh_flags:   [ SHF_ALLOC ]
    sh_size:      0xdb0           sh_type:    [ SHT_STRTAB ]
    sh_offset:    0x3f5fc         sh_entsize: 0
    sh_link:      0               sh_info:    0
    sh_addralign: 0x1       

instead.

I think I can see now how this happens: initially, sections 171 and 172
are marked for dropping.  However, later on there's this section

Section Header[174]:  sh_name: .rela.gnu.debuglto_.debug_info
    sh_addr:      0               sh_flags:   [ SHF_ALLOC ]
    sh_size:      0xc             sh_type:    [ SHT_RELA ]
    sh_offset:    0x69dc          sh_entsize: 0xc (1 entry)
    sh_link:      171             sh_info:    3
    sh_addralign: 0x4       

which causes section 171 to be retained, while 172 is still dropped,
leading to the inconsistency observed above.  Btw., GNU ld chokes on
that object just the same:

$ gld-2.29 -o ltoout-as.o ltoin-as.o
gld-2.29: ltoin-as.o: attempt to load strings from a non-string section (number
172)
ltoin-as.o: error adding symbols: Bad value

        Rainer

Reply via email to