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

ro at CeBiTec dot Uni-Bielefeld.DE gcc-bugzilla@gcc.gnu.org
Fri Sep 15 15:02:00 GMT 2017


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

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
> Thanks for the detailed analysis.  Indeed
>
>   /* Mark sections as preserved that are required by to be preserved
>      sections.  */
>   for (i = 1; i < shnum; ++i)
>     {
> ...
>       if (sh_type == SHT_SYMTAB)
>         {
>           /* Mark strings sections of copied symtabs.  */
>           if (pfnret[i - 1] == 0)
>             pfnret[sh_link - 1] = 0;
>         }
>     }
>
> so it conditionally preserves sh_link of SHT_SYMTAB.
>
> I think we need to iterate this loop.  And maybe always preserve the symtab
> since we keep exported symbols of preserved sections, we're currently lucky
> here because .debug_info always contains a relocation to .debug_abbrev.
> Probably good enough...

That worked just fine, thanks.

While there are still ld warnings

ld: warning: file /var/tmp//ccmgPmhadebugobjtem: section [2] has invalid type [
SHT_NULL ]

ro@lucy 87 > elfdump -c -I 2 cc2qd7lbdebugobjtem 
cc2qd7lbdebugobjtem: : invalid sh_type: 0

Section Header[2]:  sh_name: 
    sh_addr:      0               sh_flags:   [ SHF_EXCLUDE ]
    sh_size:      0               sh_type:    [ SHT_NULL ]
    sh_offset:    0x4980          sh_entsize: 0
    sh_link:      0               sh_info:    0
    sh_addralign: 0x10      

and there's no way to silence them from the ld command line, I should be
able to prune them for the testsuite at least.  However, the final link
fails:

Undefined                       first referenced
 symbol                             in file
__gnu_lto_v1                        /var/tmp//ccQylLjddebugobj

It turns out that __gnu_lto_v1 in the original object

  [336]     0x1    0x1  OBJT GLOB  D    0 COMMON                  __gnu_lto_v1

remains in the one produced by lto-wrapper:

  [339]      0    0  NOTY GLOB  D    0 UNDEF           __gnu_lto_v1

Need to check what's going on here...

        Rainer


More information about the Gcc-bugs mailing list