STT_IFUNC is added to GNU binutils

[H.J.]

STT_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 which returns a function pointer. If an STT_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_IFUNC symbol.

The purpose of this symbol type is it 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_IFUNC is defined in OS-specific range:

#define STT_LOOS 10 /* OS-specific semantics */
#define STT_IFUNC 10 /* Symbol is an indirect code object */
#define STT_HIOS 12 /* OS-specific semantics */

H.J.

[Michael Matz]

Hi,

On Thu, 4 Dec 2008, H.J. wrote:

> STT_IFUNC

Hey, that's quite useful. Though it's a bit strange that this was never
discussed here.

Ciao,
Michael.

[Ulrich Drepper]

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

H.J. wrote:
> #define STT_IFUNC 10 /* Symbol is an indirect code object */

That's wrong.

Either it should have been, as we discussed, be defined with the value 7.

Or: if it is kept in the OS-specific range it should be named
STT_GNU_IFUNC. That's what my original patch did.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk4WG8ACgkQ2ijCOnn/RHSWfACggqM3pOvklh1phQ/T1KoS0Cd7
zjsAoL4wKyQ4UM/XWQufDBxfxUjryeJF
=Fr5h
-----END PGP SIGNATURE-----

[H.J.]

On Dec 4, 2:23 pm, Ulrich Drepper <drep...@redhat.com> wrote:
> > #define STT_IFUNC  10      /* Symbol is an indirect code object */
>
> That's wrong.
>
> Either it should have been, as we discussed, be defined with the value 7.
>
> Or: if it is kept in the OS-specific range it should be named
> STT_GNU_IFUNC.  That's what my original patch did.
>

Should STT_IFUNC be defined as 7? Or should it be renamed to
STT_GNU_IFUNC?

If it is a useful feature to everyone, it should be changed to 7.

H.J.

[Ulrich Drepper]

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

H.J. wrote:
> Should STT_IFUNC be defined as 7? Or should it be renamed to
> STT_GNU_IFUNC?
>
> If it is a useful feature to everyone, it should be changed to 7.

In September we agreed to define it as 7.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk4XfgACgkQ2ijCOnn/RHTRCgCfR9TjoXDCogni0pwoetlIarpl
gxwAoKyOQep95Fk7qGgWevKU4uLwKS4M
=PuyT
-----END PGP SIGNATURE-----

[Dave Prosser]

As per H.J.'s request, here is my request for
clarification note I sent to him on STT_IFUNC.

-------- Original Message --------
Subject: Re: STT_IFUNC is added to GNU binutils
Date: Fri, 5 Dec 2008 09:28:00 -0800
From: H.J. Lu <hjl....@gmail.com>
To: Dave Prosser <d...@sco.com>
References: <49380D3E...@sco.com>
<6dc9ffc80812040910o6f5...@mail.gmail.com>
<6dc9ffc80812050752u216...@mail.gmail.com> <4939619B...@sco.com>

Hi Dave,

Would you mind asking it on the gABI group? My answer may not be entirely
correct.

My understanding is many performance critical functions in C library may be
optimized for different processors and/or ISA extensions. The current solutions
are

1. Provide a different libc.so for each processor/ISA.
2. Support different processor/ISA in a single function and branch to
the best match at run-time.
3. Provide a special optimized DSO for each processor/ISA
to override functions in libc.so at load-time.

STT_IFUNC will provide a new way to bind a function to the best
match at run-time in a single libc.so. So there may be some
limitations how it can/should be used. I think we need to discuss it
on the gABI group.

Thanks.

H.J.
---
On Fri, Dec 5, 2008 at 9:15 AM, Dave Prosser <d...@sco.com> wrote:
> H.J. Lu wrote:
>>
>> We are planning to move it to 7, out of OS-specific range. If gABI is
>> different, we will document this difference in GNU binutils.
>
> This is appropriate if STT_IFUNC is intended to be a
> generally applicable symbol type along with its special
> handling.
>
> I don't have to keep on top of linking enough that I
> end up needing a little help understanding these sorts
> of features, so since we're seriously considering adding
> this to the gABI, I'll need some clarification.
>
> So the idea with STT_IFUNC is that code is written to
> do a regular call to a function -
>
> ret = func(arg1, arg2, arg3);
>
> which results in an object file with an unresolved
> reference to "func", as described by a relocation entry
> that points to the call and the undefined symbol table
> entry for "func". The linker, when putting together
> a shared library or an executable, finds that this
> relocation for "func" resolves to a symbol defined with
> type STT_IFUNC.
>
> Now, if instead, it were a STT_FUNC definition, it
> would either patch the call site code with what it
> takes to directly reach the function, or it would patch
> the call site to reach a generated PLT code sequence
> for which the dynamic linker would end up doing a
> runtime lookup for "func" and assigning the matching
> GOT entry with address it finds for "func". The
> dynamic linker then hops off to the address as if it
> had been (indirectly) called from the PLT, and
> subsequent times that PLT, using its GOT entry, will
> immediately get to that address.
>
> But instead, we have a STT_IFUNC symbol definition, and
> in this case we always patch the call site code to get
> to a generated PLT code sequence. But now when the
> dynamic linker goes off to look for "func" it ends up
> (again) finding an STT_IFUNC definition. Here, the
> dynamic linker, instead of patching the matching GOT
> entry with the address it found for "func", it actually
> calls "func", passing it no arguments, and assigns the
> GOT entry the address presumed to be returned by "func".
> Then the dynamic linker hops off to that address and
> later uses of the PLT immediately head to that same
> address.
>
> Assuming I've got the above correct, I've some further
> questions.
>
> For threaded programs, the dynamic linker's lazy lookup
> process requires a mutex around the whole lookup and
> GOT assignment sequence. Moreover, it has to take care
> that it cannot get into deadlock situations doing so,
> such as needing to do a dynamic lookup while in the
> process of doing another lookup.
>
> To handle the the user callable dl...() routines, the
> dynamic linker needs to use a recursive mutex as they
> can get back to them selves, say, for example, when
> doing a shared library's initialization code while in
> a dlopen() of that library.
>
> It would seem that either one has to put severe
> limitations on what the STT_IFUNC routine can access
> or the dynamic linker would be forced to use the
> heavier weight recursive mutexes for *every* lazy
> function lookup just in case it happened to resolve
> to a STT_IFUNC so that we can safely call the
> pointed-to routine within a threaded program, yes?
>
> Also, is there any expectation of *when* or how
> often an STT_IFUNC routine is or can be called? Is
> it reasonable to expect that, for the lifetime of
> a process, that all calls to a STT_IFUNC will return
> the same result? Or, is it possible for such
> functions to return values that depend on, for
> example, whether multiple CPUs are enabled on the
> system...something that some OSes can turn on and
> off without needing reboots.
>
> Sorry if this is all stuff that's been hashed out
> before, but I don't think any of it wandered across
> my mailbox before now.

--
Dave Prosser d...@sco.com (973)261-1407 The SCO Group, Florham Park, NJ
SCO is a leading provider of UNIX-based solutions and mobile services.