[PATCH] PR ld/21402: Skip PIE indirect5 and indirect6 tests on i386

H.J. Lu hjl.tools@gmail.com
Mon Apr 24 20:51:00 GMT 2017


On Sun, Apr 23, 2017 at 9:09 PM, Alan Modra <amodra@gmail.com> wrote:
> On Fri, Apr 21, 2017 at 11:37:34AM -0700, H.J. Lu wrote:
>> @@ -2863,10 +2867,14 @@ elf_i386_allocate_dynrelocs (struct elf_link_hash_entry *h, void *inf)
>>        int tls_type = elf_i386_hash_entry(h)->tls_type;
>>
>>        /* Make sure this symbol is output as a dynamic symbol.
>> -      Undefined weak syms won't yet be marked as dynamic.  */
>> +      Undefined weak syms won't yet be marked as dynamic.
>> +      PR ld/21402: If this symbol isn't undefined weak symbol,
>> +      don't make it dynamic in PIE.   */
>>        if (h->dynindx == -1
>>         && !h->forced_local
>> -       && !resolved_to_zero)
>> +       && !resolved_to_zero
>> +       && (h->root.type == bfd_link_hash_undefweak
>> +           || !bfd_link_pie (info)))
>>       {
>>         if (! bfd_elf_link_record_dynamic_symbol (info, h))
>>           return FALSE;
>
> This doesn't look correct to me.  Sure, it fixes the particular
> testcase, but why do you make non-pie non-undefweak symbols dynamic
> here?  I believe that only undefweak symbols should be made dynamic
> here, and in all the other places in allocate_dynrelocs.
>
> x86_64 too, but fixing allocate_dynrelocs for x86_64 causes no-plt-1e
> to fail due to lack of a relative GOT dynamic reloc on
>         cmpq    func@GOTPCREL(%rip), %rax
> in no-plt-check1.S.  Seems like x86_64 would need something like your
> change to elf32-i386.c to emit relative GOT dynamic relocs in
> relocate_section.  (For powerpc I decided to only handle plt and copy
> relocs in finish_dynamic_symbol.  GOT dynamic relocs are all handled
> in relocate_section as otherwise there is a lot of duplication and IMO
> less comprehensible code.)
>
>> @@ -3818,6 +3826,7 @@ elf_i386_relocate_section (bfd *output_bfd,
>>        bfd_vma st_size;
>>        asection *resolved_plt;
>>        bfd_boolean resolved_to_zero;
>> +      bfd_boolean relative_reloc;
>>
>>        r_type = ELF32_R_TYPE (rel->r_info);
>>        if (r_type == R_386_GNU_VTINHERIT
>> @@ -4268,6 +4277,7 @@ r_386_got32:
>>         if (htab->elf.sgot == NULL)
>>           abort ();
>>
>> +       relative_reloc = FALSE;
>>         if (h != NULL)
>>           {
>>             bfd_boolean dyn;
>> @@ -4301,6 +4311,17 @@ r_386_got32:
>>                     bfd_put_32 (output_bfd, relocation,
>>                                 htab->elf.sgot->contents + off);
>>                     h->got.offset |= 1;
>> +
>> +                   if (h->dynindx == -1
>> +                       && !h->forced_local
>> +                       && h->root.type != bfd_link_hash_undefweak
>> +                       && bfd_link_pie (info))
>> +                     {
>> +                       /* PR ld/21402: If this symbol isn't dynamic
>> +                          in PIE, generate R_386_RELATIVE here.  */
>> +                       eh->no_finish_dynamic_symbol = 1;
>> +                       relative_reloc = TRUE;
>> +                     }
>>                   }
>>               }
>>             else
>
> This also looks odd.  Surely you need a relative reloc when pic, not
> pie?  It seems to me you need one any time you won't be calling
> finish_dynamic_symbol (which is where x86 sets most dynamic GOT
> relocs) and have a symbol that doesn't resolve to zero.
>

I checked in this patch for i386.  I will look into x86-64.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-i386-Force-symbol-dynamic-if-it-isn-t-undefined-weak.patch
Type: text/x-patch
Size: 3435 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20170424/676f390c/attachment.bin>


More information about the Binutils mailing list