This is the mail archive of the 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 09/05/16 11:28, Will Newton wrote:
On Mon, May 9, 2016 at 11:23 AM, Jiong Wang <> wrote:
On 27/09/13 10:39, Will Newton wrote:
Add support for STT_GNU_IFUNC symbols to the AArch64 bfd backend. The
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
     elf_link_hash_traverse (&htab->root, elfNN_aarch64_allocate_dynrelocs,

+  /* Allocate global ifunc sym .plt and .got entries, and space for
+     ifunc sym dynamic relocs.  */
+  elf_link_hash_traverse (&htab->root,
+                       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).

I see, thanks very much for the info.


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