This is the mail archive of the
mailing list for the binutils project.
RE: IFUNC question (MIPS)
- From: Jack Carter <Jack dot Carter at imgtec dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 12 Aug 2013 15:10:39 +0000
- Subject: RE: IFUNC question (MIPS)
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE01AAA7C3 at BADAG02 dot ba dot imgtec dot org>,<20130812050647 dot GF3294 at bubble dot grove dot modra dot org>
Thanks for replying.
I have fixed the iplt issues and with the exception of the indirect function being external to the resolver which by definition is illegal:
"Finally, the indirect function needs to be defined in the same translation unit as the resolver function: "
It seems to be working as advertised.
I am working up an initial patch in the next few days. It will be my first binutils patch so I expect corrective feedback :-)
From: Alan Modra [email@example.com]
Sent: Sunday, August 11, 2013 10:06 PM
To: Jack Carter
Subject: Re: IFUNC question (MIPS)
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