https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
> --- Comment #39 from Richard Biener <rguenth at gcc dot gnu.org> ---
[...]
>> * On x86, of the previous 32 ld: fatal: has invalid sh_info errors, 16
>> are now gone.
>>
>> However, I've many (1284 in g++.log) instances of
>>
>> ld: warning: symbol .symtab[2] has invalid section index; ignored:
>> (file /var/tmp//ccyttLYbdebugobjtem value=9);
>>
>> Those links end with
>>
>> ld: fatal: file /var/tmp//ccyttLYbdebugobjtem: section
>> [6].rel.gnu.debuglto_.debug_info: has invalid sh_info: 9
>>
>> and ld SEGVing, again in the ld -r step.
>>
>> The warnings are from symtab entries like
>>
>> Symbol Table Section: .symtab
>> index value size type bind oth ver shndx name
>> [0] 0 0 NOTY LOCL D 0 UNDEF
>> [1] 0 0 FILE LOCL D 0 ABS pr42987_0.C
>> [2] 0 0 NOTY LOCL D 0 9
>>
>> and section 9 doesn't exist, where the input object (cp_lto_pr42987_0.o)
>> has
>
> Just guessing that it maybe doesn't like NOTYPE on local defs? I would
I don't think so. With your patch, the affected symbols are SECT
instead of LOCL, otherwise no difference.
> expect that before the partial link step that section 9 would exist.
It does indeed as I mentioned (cp_lto_pr42987_0.o is the input object
corresponding to ccyttLYbdebugobjtem).
> Does
>
> Index: libiberty/simple-object-elf.c
> ===================================================================
> --- libiberty/simple-object-elf.c (revision 256070)
> +++ libiberty/simple-object-elf.c (working copy)
> @@ -1400,9 +1400,9 @@ simple_object_elf_copy_lto_debug_section
> gnu_lto - strings);
> ELF_SET_FIELD (type_functions, ei_class, Sym,
> ent, st_shndx, Elf_Half, SHN_UNDEF);
> + *st_info = ELF_ST_INFO (bind, STT_NOTYPE);
> }
> *st_other = other;
> - *st_info = ELF_ST_INFO (bind, STT_NOTYPE);
> ELF_SET_FIELD (type_functions, ei_class, Sym,
> ent, st_value, Elf_Addr, 0);
> ELF_SET_FIELD (type_functions, ei_class, Sym,
>
> fix these errors?
Unfortunately not: it's really the section index pointing to the
non-existing (i.e. eliminated) .gnu.debuglto_.debug_info section.
Rainer
