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

[rguenther at suse dot de]

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

--- Comment #56 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 10 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
> 
> --- Comment #55 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 
> Uni-Bielefeld.DE> ---
> > --- Comment #54 from Richard Biener <rguenth at gcc dot gnu.org> ---
> > Created attachment 43075
> >   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43075&action=edit
> > Updated patch with SHT_GROUP and extended section index handling
> >
> > More fixes accumulated.  Works for the large # input section testcase now. 
> > Also goes happily into stage2 with bootstrap-lto.
> 
> Solaris ld is almost happy again with this patch :-)
> 
> There's one last failure remaining:
> 
> FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 (test for excess errors)
> Excess errors:
> ld: fatal: relocation error: R_386_32: file /var/tmp//cctCq6ccdebugobjtem:
> section [11].rel.debug_macro: symbol
> .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574 (section): symbol has been
> discarded with discarded section:
> [6].debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574
> 
> Compiling the test with -save-temps works, however...
> 
> Here's what I find: the error happens during the ld -r stage again.  The
> invocations boil down to
> 
> $ lto-wrapper pr41893-1.o pr41893-2.o
> $ ld -r -o ccO7nK8bdebugobj cc0vpSPddebugobjtem ccTcSAFadebugobjtem
> 
> elfdump complains about those objects:
> 
> cc0vpSPddebugobjtem: [2: .group%wm4.0.3a71fa84800da6806674b2243f0bb574][2]:
> invalid section index: 0
> 
> as can be seen with elfdump -g:
> 
> Group Section:  .group%wm4.0.3a71fa84800da6806674b2243f0bb574
>   Signature Symbol: wm4.0.3a71fa84800da6806674b2243f0bb574
>   Members:
>     index   flags / section
>       [0]   [ COMDAT ]
>       [1]   .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574
>       [2]   <invalid section>
> 
> while readelf -g doesn't seem to care about the section index here:
> 
> COMDAT group section [    2] `.group%wm4.0.3a71fa84800da6806674b2243f0bb574'
> [wm4.0.3a71fa84800da6806674b2243f0bb574] contains 2 sections:
>    [Index]    Name
>    [    6]   .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574
>    [    0]   
> 
> The input object had
> 
>  COMDAT group section [    2] `.group%wm4.0.3a71fa84800da6806674b2243f0bb574'
> [wm4.0.3a71fa84800da6806674b2243f0bb574] contains 2 sections:
>    [Index]    Name
>    [    7]   .gnu.debuglto_.debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574
>    [   25]   .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574
> 
>         Rainer

I can reproduce that with -ffat-lto-objects where indeed we somehow
get confused when we should preserve only part of a SHT_GROUP given
we don't "prune" groups.  The question to me is why do we put
both macro sections in a single group ...  but that's probably
an artifact on how things are supposed to work in the end...
[I wonder if SHF_EXCLUDE works "properly" for group members when
doing a non-LTO link]

Anyway, this should be "easy" to fix with sth like

      else if (sh_type == SHT_GROUP)
        {
          /* Remap section indices in groups and remove removed members.  
*/
          unsigned char *ent, *dst;
          for (dst = ent = buf + 4; ent < buf + length - 4; ent += 4)
            {
              unsigned shndx = type_functions->fetch_Elf_Word (ent);
              if (pfnret[shndx - 1] == -1)
                ;
              else
                {
                  type_functions->set_Elf_Word (dst, sh_map[shndx]);
                  dst += 4;
                }
            }
          /* Adjust the length.  */
          length = dst - buf;
        }

in the group handling.

That fixes -ffat-lto-objects handling for me with the testcase.
Will re-test with that.