Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

H.J. Lu-30
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 */
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Jan Beulich
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" <[hidden email]> 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 */

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Ulrich Drepper
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Beulich 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.

The static symbol table is gone.  But aside from that, there is no
existing relocation which meets the requirements.  The lookup must only
ever happen locally and not along the search path.  Beside, anything but
the proposed relocation is an unnecessary burden.


> 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.

Huh?  This new relocation type only exists in executables.


> and hence meaningless for
> OSes not supporting STT_GNU_IFUNC).

The symbol type is OS-specific after talking with stakeholders in other
OS.  And it's not my fault that there is no OS-specific range for
relocations.  There are enough numbers left for x86 and x86-64 so that
this isn't an issue.

I don't know HJ's reasons for posting this on this list.  I don't
consider any of this up for discussion.  If some OS wants to not
implement this, by all means, don't do it.  This doesn't mean the rest
can or should be held back.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkob/b0ACgkQ2ijCOnn/RHQBPACfTegEnc4w2me8JlBNcQ8s9w7E
XG0AoJ2k8slWf0kE3aTJbywUEzzZXS8Q
=zhK3
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

H.J. Lu-30
In reply to this post by Jan Beulich
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 <[hidden email]> 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" <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

H.J. Lu-30
In reply to this post by Ulrich Drepper
>
> I don't know HJ's reasons for posting this on this list.  I don't
> consider any of this up for discussion.  If some OS wants to not
> implement this, by all means, don't do it.  This doesn't mean the rest
> can or should be held back.
>

It is mainly informationally so that I can refer people to this post later
if someone is interested in it.


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Jan Beulich
In reply to this post by H.J. Lu-30
>>> "H.J. Lu" <[hidden email]> 26.05.09 16:39 >>>
>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.

The fundamental difference is that the new-relocation-type approach is
not matching the general ELF idea, whereas the new dynamic-tag-approach
fits well with other ELF definitions.

Jan

Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

H.J. Lu-30
On Tue, May 26, 2009 at 8:31 AM, Jan Beulich <[hidden email]> wrote:

>>>> "H.J. Lu" <[hidden email]> 26.05.09 16:39 >>>
>>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.
>
> The fundamental difference is that the new-relocation-type approach is
> not matching the general ELF idea, whereas the new dynamic-tag-approach
> fits well with other ELF definitions.
>

Relocation types are defined in the psABI. I don't see any problems
with R_X86_64_IRELATIVE.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Ian Lance Taylor-3
In reply to this post by H.J. Lu-30
"H.J. Lu" <[hidden email]> writes:

> 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.

One difference is that a new relocation has to be defined for every
processor ABI separately.  New DT_* tags can be defined once.

Ian
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Jakub Jelinek
On Tue, May 26, 2009 at 09:30:42AM -0700, Ian Lance Taylor wrote:

> "H.J. Lu" <[hidden email]> writes:
>
> > 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.
>
> One difference is that a new relocation has to be defined for every
> processor ABI separately.  New DT_* tags can be defined once.

The new relocation types aren't useful just for hidden/local
STT_GNU_IFUNC, but also for prelink, which in .gnu.conflict section
needs to preresolve a normal relocation against STT_GNU_IFUNC symbol
into some kind of relocation which ensures that a function is called
and result returned.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Rod Evans
In reply to this post by H.J. Lu-30
Late last year there was a discussion in regards STT_IFUNC, and we
thought you'd settled on this name (no _GNU_) and the associated
value of 7.

I guess we jumped the gun.  Although we have no immediate plans to
implement support for this, we did reserve the name-space, so that
if nothing else we could identify new objects with this definition:

  sys/elf.h:#define   STT_IFUNC   7   /* indirect code object (unused) */


I assume we should now remove this dead-wood and reserve the STT_LOOS
value instead.

--

Rod.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

H.J. Lu-30
On Tue, May 26, 2009 at 9:40 AM, Rod Evans <[hidden email]> wrote:

> Late last year there was a discussion in regards STT_IFUNC, and we
> thought you'd settled on this name (no _GNU_) and the associated
> value of 7.
>
> I guess we jumped the gun.  Although we have no immediate plans to
> implement support for this, we did reserve the name-space, so that
> if nothing else we could identify new objects with this definition:
>
>  sys/elf.h:#define   STT_IFUNC   7   /* indirect code object (unused) */
>
>
> I assume we should now remove this dead-wood and reserve the STT_LOOS
> value instead.
>

Personally, I'd like to see

#define   STT_IFUNC   7   /* indirect code object (unused) */

But since 7 is the last used generic symbol type and not all OSes
agree on STT_IFUNC, we moved it to OS specific range. We can't
wait forever on STT_IFUNC. If we want STT_IFUNC, we should
do it now. Otherwise we will use STT_GNU_IFUNC.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

H.J. Lu-30
In reply to this post by Ian Lance Taylor-3
On Tue, May 26, 2009 at 9:30 AM, Ian Lance Taylor <[hidden email]> wrote:

> "H.J. Lu" <[hidden email]> writes:
>
>> 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.
>
> One difference is that a new relocation has to be defined for every
> processor ABI separately.  New DT_* tags can be defined once.
>

Sure. But R_*_IRELATIVE is much simpler to implement in static and
dynamic linkers.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Ian Lance Taylor-5
"H.J. Lu" <[hidden email]> writes:

> On Tue, May 26, 2009 at 9:30 AM, Ian Lance Taylor <[hidden email]> wrote:
>> "H.J. Lu" <[hidden email]> writes:
>>
>>> 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.
>>
>> One difference is that a new relocation has to be defined for every
>> processor ABI separately.  New DT_* tags can be defined once.
>>
>
> Sure. But R_*_IRELATIVE is much simpler to implement in static and
> dynamic linkers.

That is not a convincing argument when it comes to standardizing
something.  The DT_* tags are not difficult to implement.

Jakub's comment about prelink seems relevant, however.

Ian
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

H.J. Lu-30
In reply to this post by H.J. Lu-30
On Tue, May 26, 2009 at 8:43 AM, H.J. Lu <[hidden email]> wrote:

> On Tue, May 26, 2009 at 8:31 AM, Jan Beulich <[hidden email]> wrote:
>>>>> "H.J. Lu" <[hidden email]> 26.05.09 16:39 >>>
>>>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.
>>
>> The fundamental difference is that the new-relocation-type approach is
>> not matching the general ELF idea, whereas the new dynamic-tag-approach
>> fits well with other ELF definitions.
>>
>
> Relocation types are defined in the psABI. I don't see any problems
> with R_X86_64_IRELATIVE.
>
Here is the proposed update for x86-64 psABI.


--
H.J.

x86-64-psABI-ifunc-1.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Ulrich Drepper
In reply to this post by Rod Evans
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rod Evans wrote:
> Late last year there was a discussion in regards STT_IFUNC, and we
> thought you'd settled on this name (no _GNU_) and the associated
> value of 7.

No.  Because _you_ said you don't want this we settled on an OS-specific
value and name.


> I assume we should now remove this dead-wood and reserve the STT_LOOS
> value instead.

Why reserve it?  It's OS-specific.  Nobody will crowd that range but you
and if you should use it and it's a different value, then it doesn't
matter either.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkocKdwACgkQ2ijCOnn/RHRRWwCfbSofNRTx5qCs4fm+LC6xUQvQ
LFIAoKFxCU72dVRRV1TqH+86lyKKknDK
=MtoW
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Rod Evans
Ulrich Drepper wrote:

> Rod Evans wrote:
>> Late last year there was a discussion in regards STT_IFUNC, and we
>> thought you'd settled on this name (no _GNU_) and the associated
>> value of 7.
>
> No.  Because _you_ said you don't want this we settled on an OS-specific
> value and name.

I said I had some reservations about it's implementation, and that we
had no immediate plans on implementing it.  We thought the number had
been decided.

>> I assume we should now remove this dead-wood and reserve the STT_LOOS
>> value instead.
>
> Why reserve it?  It's OS-specific.  Nobody will crowd that range but you
> and if you should use it and it's a different value, then it doesn't
> matter either.

We try and keep track of various ELF definitions, so that we can at
least identify them in a user friendly manner.


--

Rod.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

H.J. Lu-30
In reply to this post by Jan Beulich
On Mon, May 25, 2009 at 11:52 PM, Jan Beulich <[hidden email]> 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" <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Ulrich Drepper
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

H.J. Lu wrote:
> 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.

And?  Relocations of course also work in all the cases.

It is a braindead idea to invent a new data structure every time some
gets added.  Especially if there is already one which perfectly fits the
bill.  There is no reason whatsoever to not use a relocation.  The
introduction of a DT_* described data structure just makes things more
complicated at runtime.

The argument that only one thing for all architectures has to be changed
is irrelevant.  The amount of work needed in the linker in negligible.
On the other hand, there have to be completely different implementations
for the fancy new data structure for different architectures if the
function pointer implementation differs.


Using R_*_IRELATIVE relocations is the right way to handle this.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkodd/sACgkQ2ijCOnn/RHQXiQCePW4Wf0gVofc/9++SwpS1d3vZ
w0oAnieTzz2TyHidIWQW6QLqAHNjh7dj
=hyef
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

H.J. Lu-30
On Wed, May 27, 2009 at 10:27 AM, Ulrich Drepper <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> H.J. Lu wrote:
>> 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.
>
> And?  Relocations of course also work in all the cases.
>
> It is a braindead idea to invent a new data structure every time some
> gets added.  Especially if there is already one which perfectly fits the
> bill.  There is no reason whatsoever to not use a relocation.  The
> introduction of a DT_* described data structure just makes things more
> complicated at runtime.
>
> The argument that only one thing for all architectures has to be changed
> is irrelevant.  The amount of work needed in the linker in negligible.
> On the other hand, there have to be completely different implementations
> for the fancy new data structure for different architectures if the
> function pointer implementation differs.
>
>
> Using R_*_IRELATIVE relocations is the right way to handle this.
>

How to do you handle R_*_PC32 relocation to a locally defined
STT_GNU_IFUNC symbol in dynamic and static executables?


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

Ulrich Drepper
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

H.J. Lu wrote:
> How to do you handle R_*_PC32 relocation to a locally defined
> STT_GNU_IFUNC symbol in dynamic and static executables?

When I compile the test code you sent yesterday I see this in the
executable:

000000000040050c <main>:
  40050c:       55                      push   %rbp
  40050d:       48 89 e5                mov    %rsp,%rbp
  400510:       bf fd ff ff ff          mov    $0xfffffffd,%edi
  400515:       e8 00 00 00 00          callq  40051a <main+0xe>
  40051a:       b8 00 00 00 00          mov    $0x0,%eax
  40051f:       c9                      leaveq
  400520:       c3                      retq


This is of course not going to work.  The program doesn't even contain a
R_*_IRELATIVE relocation.

Every call to an IFUNC must be indirect somewhere.  You cannot change
the relative jmp into an indirect one (opcode is too long).  Therefore,
as I explained before, you allocate and jump to a PLT slot.  The PLT
slot as a GOT entry and that GOT entry in modified by the R_*_IRELATIVE
relocation.

Of course something can be wrong with the code I get.  So, why don't you
take the time to actually explain what you see at the asm level.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkodflIACgkQ2ijCOnn/RHSk0ACgqqWSCBZ8Mu+vmC1ELvtBeZWA
/I8AoKo14TajUZ8ovA0SUYBSkvEKBJLZ
=eYJl
-----END PGP SIGNATURE-----
123