Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

["H.J. Lu" <hjl dot tools at gmail dot 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.