[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