Proposal for STT_GNU_IFUNC and R_*_IRELATIVE
Jan Beulich
JBeulich@novell.com
Tue May 26 14:21:00 GMT 2009
I have to admit that I don't see why a new symbol type *and* a new
relocation type would be necessary here. If the to-be-relocated symbols'
name is to not appear in the original (dynamic) symbol table, then all that is
needed is a second relocation section referencing a second (in the case of
non-ET_REL objects perhaps the static) symbol table. Whether this split
would really be necessary in ET_REL objects I doubt in the first place, so
it's perhaps just a job of the static linker to separate the relocations
accordingly. The consequence would be the need for a new set of DT_*
tags, which, along with the symbol type, ought to be OS-specific (whereas
the new relocation type is OS-independent, and hence meaningless for
OSes not supporting STT_GNU_IFUNC).
Jan
>>> "H.J. Lu" <hjl.tools@gmail.com> 25.05.09 20:56 >>>
Hi,
Here is a proposal for STT_GNU_IFUNC and R_*_IRELATIVE. It
has been implemented in the Linux binutils 2.19.51.0.5.
H.J.
----
STT_GNU_IFUNC
This symbol type is the same as STT_FUNC except that it always
points to a function or piece of executable code which takes no
arguments and returns a function pointer. If an STT_GNU_IFUNC
symbol is referred to by a relocation, then evaluation of that
relocation is delayed until load-time. The value used in the
relocation is the function pointer returned by an invocation
of the STT_GNU_IFUNC symbol.
The purpose of this symbol type is to allow the run-time to
select between multiple versions of the implementation of a
specific function. The selection made in general will take the
currently available hardware into account and select the most
appropriate version.
STT_GNU_IFUNC is defined in OS-specific range:
#define STT_LOOS 10 /* OS-specific semantics */
#define STT_GNU_IFUNC 10 /* Symbol is an indirect code object */
#define STT_HIOS 12 /* OS-specific semantics */
R_*_IRELATIVE
This relocation is similar to R_*_RELATIVE except that the
value used in this relocation is the program address returned
by the function, which takes no arguments, at the address of
the result of the corresponding R_*_RELATIVE relocation.
The purpose of this relocation to avoid name lookup for locally
defined STT_GNU_IFUNC symbols at load-time.
R_*_IRELATIVE is defined for i386 and x86-64:
#define R_386_IRELATIVE 42 /* Adjust indirectly by program base */
#define R_X86_64_IRELATIVE 37 /* Adjust indirectly by program base */
More information about the Libc-alpha
mailing list