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

--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
On September 15, 2017 5:02:36 PM GMT+02:00, "ro at CeBiTec dot
Uni-Bielefeld.DE" <gcc-bugzi...@gcc.gnu.org> wrote:
>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.

Can you report this issue to the Solaris folks? 

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

How does it fail? The symbol should be unused...

Richard. 

>        Rainer

Reply via email to