This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE


We have 2 issues:

1. Should the new type be generic or OS specific?

Since only Linux is interested in the new type, we make it OS specific.

2. How should locally defined symbols with the new type be handled?

I don't see the fundamental difference between the new relocation and
the new DT_* tags. The end result is the same. If your OS doesn't support
them, the application will crash if they are used. I will propose a new
x86-64 psABI extension, which will be optional. If an OS supports
STT_GNU_IFUNC, it must support R_X86_64_IRELATIVE.


H.J.
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).
>
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]