This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: Generic System V Application Binary Interface <generic-abi at googlegroups dot com>, IA32 System V Application Binary Interface <ia32-abi at googlegroups dot com>, Ulrich Drepper <drepper at redhat dot com>, Nick Clifton <nickc at redhat dot com>, Binutils <binutils at sourceware dot org>, GNU C Library <libc-alpha at sourceware dot org>, discuss at x86-64 dot org
- Date: Wed, 27 May 2009 06:09:11 -0700
- Subject: Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE
- References: <6dc9ffc80905251156p1ab274aey8e52be086fd88749@mail.gmail.com> <4A1BADCA02000078000027BB@vpn.id2.novell.com>
On Mon, May 25, 2009 at 11:52 PM, Jan Beulich <JBeulich@novell.com> wrote:
> 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).
After looking another look, DT_* may be a good idea. STT_GNU_IFUNC
can be in DSO, dynamic executable and static executable. We need a way
to make it to work for all 3 cases. I think we can use DT_XXX to mark the
indirect relocation table for relocations against locally defined STT_GNU_IFUNC
symbols
DT_IRELA
This element holds the address of the indirect relocation table with
explicit addends, such as Elf32_Rela for the 32-bit file class or
Elf64_Rela for the 64-bit file class. If this element is present,
the dynamic
structure must also have DT_IRELASZ and DT_IRELAENT elements.
DT_IRELASZ
This element holds the total size, in bytes, of the DT_IRELA
relocation table.
DT_IRELAENT
This element holds the size, in bytes, of the DT_IRELA relocation entry.
DT_IREL
This element is similar to DT_IRELA, except its table has implicit
addends, such as Elf32_Rel for the 32-bit file class or Elf64_Rel for
the 64-bit file class. If this element is present, the dynamic structure
must also have DT_IRELSZ and DT_IRELENT elements.
DT_IRELSZ
This element holds the total size, in bytes, of the DT_IREL
relocation table.
DT_IRELENT
This element holds the size, in bytes, of the DT_IREL relocation entry.
Relocations in the indirect relocation table don't require name lookup
and their symbol values are zero. The value used in the relocation is
the program address returned by the function, which takes no arguments,
at the address of the result of the corresponding R_*_* relocation.
The purpose of the indirect relocation table to support executables and
avoid name lookup for locally defined STT_GNU_IFUNC symbols at load-time.
The indirect relocation table is optional. Either DT_IRELA or DT_IREL may
occur, not both. It should processed as soon as the object is relocated.
H.J.
> 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 */
>
>
--
H.J.