This is the mail archive of the
mailing list for the binutils project.
Re: IFUNC question (MIPS)
- From: Alan Modra <amodra at gmail dot com>
- To: Jack Carter <Jack dot Carter at imgtec dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 12 Aug 2013 14:36:47 +0930
- Subject: Re: IFUNC question (MIPS)
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE01AAA7C3 at BADAG02 dot ba dot imgtec dot org>
On Thu, Aug 01, 2013 at 05:51:54PM +0000, Jack Carter wrote:
> I have gotten ifunc to work for MIPS o32 and don't like the overhead of my solution.
> My assumption is that the calls and references in the "resolver" function can be external to the a.out or dso that the "resolver" function resides. Is this true, or do we restrict what can be in the "resolver" function?
The resolver can be external, but this feature isn't a particularly
good one IMNSHO. Calls to the resolver happen during ld.so relocation
processing, so it's all too possible to call a resolver function in an
object that hasn't yet been relocated. In fact, you can do that even
in the same object if you order relocations poorly. See
ppc_elf_reloc_type_class for one way to sort relocations properly when
using -z combreloc. (x64_64 hacks ld.so instead.)
> I currently make all ifunc entry points in the .dynsym be the .iplt stubs.
You have a problem there if your ifunc implementation needs to do
something special for ifunc over and above that done for normal
dynamic functions. The point I'm making is that at link time you may
not know that an undefined symbol will resolve to an ifunc.
Australia Development Lab, IBM