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

[Jiong Wang <jiong dot wang at foss dot arm dot com>]

On 09/05/16 11:28, Will Newton wrote:
> 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).

I see, thanks very much for the info.

Regards,
Jiong