This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Basic STT_GNU_IFUNC question(s)
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Jack Carter <Jack dot Carter at imgtec dot com>
- Cc: "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 16 May 2013 08:08:44 +0100
- Subject: Re: Basic STT_GNU_IFUNC question(s)
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE010EBF51 at bamail02 dot ba dot imgtec dot org>
Jack Carter <Jack.Carter@imgtec.com> writes:
> Hi,
>
> I've been trying to do the MIPs port for IFUNC based on the ARM port and keep
> stumbling.
>
> For a pure shared object with just the defining ifunc routines, there seems to
> be neither .iplt stubs nor R_ARM_IRELATIVE relocations which leads me to
> believe that ld.so upon loading runs the function pointed to by the
> STT_GNU_IFUNC dynamic symbol and updates its tables from the resulting address.
>
> Is this true or have I missed something?
Yeah, it's true.
> If that is true, then what triggers ld.so to behave differently for this case?
In the ARM case we can use a PLT, so it gets done by the elf_ifunc_invoke
call in _dl_fixup. I would have expected the same to be true for MIPS
if you're using -mplt. But remember that MIPS has its own traditional
lazy-binding stubs, which use a different routine (dl-trampoline.c:
__dl_runtime_resolve). You'll need to add similar code there.
You also need to call elf_ifunc_invoke in the MIPS elf_machine_rel and
elf_machine_rela functions.
Richard