This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] aarch64: Add support for GNU indirect functions.


On Mon, May 9, 2016 at 11:23 AM, Jiong Wang <jiong.wang@arm.com> wrote:
> On 27/09/13 10:39, Will Newton wrote:
>>
>> Add support for STT_GNU_IFUNC symbols to the AArch64 bfd backend. The
>> tests
>> are ported from the ld-ifunc tests but are enabled for cross builds so can
>> be run easily without hardware or a simulator.
>>
>> This version of the patch uses two passes over the symbols to ensure that
>> the dynamic relocs are output in the correct order.
>>
>>
>>       (elfNN_aarch64_allocate_ifunc_dynrelocs): New function.
>>       (elfNN_aarch64_allocate_local_ifunc_dynrelocs): New function.
>>
>>
>>   /* This is the most important function of all . Innocuosly named
>>      though !  */
>> @@ -5987,6 +6421,20 @@ elfNN_aarch64_size_dynamic_sections (bfd
>> *output_bfd ATTRIBUTE_UNUSED,
>>     elf_link_hash_traverse (&htab->root, elfNN_aarch64_allocate_dynrelocs,
>>                         info);
>>
>> +  /* Allocate global ifunc sym .plt and .got entries, and space for
>> global
>> +     ifunc sym dynamic relocs.  */
>> +  elf_link_hash_traverse (&htab->root,
>> elfNN_aarch64_allocate_ifunc_dynrelocs,
>> +                       info);
>> +
>> +  /* Allocate .plt and .got entries, and space for local symbols.  */
>> +  htab_traverse (htab->loc_hash_table,
>> +              elfNN_aarch64_allocate_local_dynrelocs,
>> +              info);
>> +
>> +  /* Allocate .plt and .got entries, and space for local ifunc symbols.
>> */
>> +  htab_traverse (htab->loc_hash_table,
>> +              elfNN_aarch64_allocate_local_ifunc_dynrelocs,
>> +              info);
>
>
> Hi Will,
>
>   I came across above code where extra traverses are introduced for
> IFUNC symbo, any particular
>   reason we need this? purely to make sure IFUNC runtime relocations
> happens last? If it is, I
>   noticed you are using next_jump_slot_index/next_irelative_index
> mechanism to guarantee the
>   relocation order in your initial aarch64 IFUNC support, why it's
> dropped in your final version?

Hi Jiong,

Yes, its to ensure ordering of the ifunc relocs for runtime
resolution. The next_irelative_index method proved to be unreliable
but I cannot recall the precise reason why. I would guess that if you
try switching it back then one of the tests will fail (although some
of this stuff is really hard to test as it interacts so much with the
dynamic linker).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]