Proposal for STT_GNU_IFUNC and R_*_IRELATIVE
H.J. Lu
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 */
Jan Beulich
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....@gmail.com> 25.05.09 20:56 >>>
Ulrich Drepper
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-----
H.J. Lu
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.
--
H.J.
H.J. Lu
> 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.
Jan Beulich
>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
H.J. Lu
Relocation types are defined in the psABI. I don't see any problems
with R_X86_64_IRELATIVE.
--
H.J.
Rod Evans
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.
H.J. Lu
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.
H.J. Lu
> "H.J. Lu" <hjl....@gmail.com> 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.
>
> 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.
Ian Lance Taylor
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
H.J. Lu
Here is the proposed update for x86-64 psABI.
--
H.J.
Ulrich Drepper
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-----
Rod Evans
> 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.
H.J. Lu
> 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.
--
H.J.
Ulrich Drepper
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-----
H.J. Lu
> -----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.
Ulrich Drepper
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-----
H.J. Lu
>
> -----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
I got
00000000004005ac <main>:
4005ac: 55 push %rbp
4005ad: 48 89 e5 mov %rsp,%rbp
4005b0: bf fd ff ff ff mov $0xfffffffd,%edi
4005b5: e8 00 00 00 00 callq 4005ba <main+0xe>
4005ba: b8 00 00 00 00 mov $0x0,%eax
4005bf: c9 leaveq
Relocation section '.rela.ifunc.dyn' at offset 0x430 contains 1 entries:
Offset Info Type Sym. Value Sym. Name + Addend
0000004005b6 000400000002 R_X86_64_PC32 foo() foo - 4
Dynamic linker will lookup STT_GNU_IFUNC foo and resolve
R_X86_64_PC32. But dynamic linker will segfaut as soon as
it tries to run foo () since the text segment isn't executable
when it is changed to PROT_READ|PROT_WRITE before
updating the text segment.
>
> 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.
>
The current linker doesn't do that. I will investigate if it is easy to fix,
especially for static executables where executable has to manage
PLT and GOT itself. Certain static executables like kernel may
have
call STT_GNU_IFUNC foo
where the best foo will be selected at boot time for a given hardware.
PLT/GOT isn't needed here.
--
H.J.
Ulrich Drepper
Hash: SHA1
H.J. Lu wrote:
> I got
>
> 00000000004005ac <main>:
> 4005ac: 55 push %rbp
> 4005ad: 48 89 e5 mov %rsp,%rbp
> 4005b0: bf fd ff ff ff mov $0xfffffffd,%edi
> 4005b5: e8 00 00 00 00 callq 4005ba <main+0xe>
> 4005ba: b8 00 00 00 00 mov $0x0,%eax
> 4005bf: c9 leaveq
>
> Relocation section '.rela.ifunc.dyn' at offset 0x430 contains 1 entries:
> Offset Info Type Sym. Value Sym. Name + Addend
> 0000004005b6 000400000002 R_X86_64_PC32 foo() foo - 4
>
> Dynamic linker will lookup STT_GNU_IFUNC foo and resolve
> R_X86_64_PC32. But dynamic linker will segfaut as soon as
> it tries to run foo () since the text segment isn't executable
> when it is changed to PROT_READ|PROT_WRITE before
> updating the text segment.
Exactly. We must never write to a text segment. Making a text segment
writable is simply no option. It's not even possible with the
appropriate security policy in place.
Really: text relocations are no solutions. Ever. No new extension must
rely on writable text segments.
> Certain static executables like kernel may
> have
>
> call STT_GNU_IFUNC foo
>
> where the best foo will be selected at boot time for a given hardware.
> PLT/GOT isn't needed here.
This doesn't matter. Either a PLT slot has a IRELATIVE relocation
attached (no lookup, no dynamic selection) or it is a traditional PLT
jump at which point at the first call ld.so will relocate the GOT entry.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkodlNoACgkQ2ijCOnn/RHRblQCdFSUC6y35miwG+KeFCDMu+lKa
ZWQAn1lZg+KQVQ+NG29OlngxsmQ1grq2
=fOna
-----END PGP SIGNATURE-----
H.J. Lu
I will try to put my binutils on git.kernel.org.
H.J.
---
>> Certain static executables like kernel may
>> have
>>
>> call STT_GNU_IFUNC foo
>>
>> where the best foo will be selected at boot time for a given hardware.
>> PLT/GOT isn't needed here.
>
> This doesn't matter. Either a PLT slot has a IRELATIVE relocation
> attached (no lookup, no dynamic selection) or it is a traditional PLT
> jump at which point at the first call ld.so will relocate the GOT entry.
>
> - --
> ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkodlNoACgkQ2ijCOnn/RHRblQCdFSUC6y35miwG+KeFCDMu+lKa
> ZWQAn1lZg+KQVQ+NG29OlngxsmQ1grq2
> =fOna
> -----END PGP SIGNATURE-----
>
> >
>
H.J.
H.J. Lu
> Is it true that the new IRELATIVE relocation should only appear in
> .plt, and the .plt entries involved are all the size size? If so, ld
> can ensure that all such .plt entries are adjacent and emit two new
> tags giving the array location and size. No need for new relocations
> at all. Also should make ld.so a little faster.
>
Those RELATIVE relocations only appear in .got.plt on x86. They may
appear in shared library, static executable and dynamic executable.
I have marked them in static executables. I will see if I can mark
them in shared library and dynamic executable.
--
H.J.
Ulrich Drepper
Hash: SHA1
Alan Modra wrote:
> Is it true that the new IRELATIVE relocation should only appear in
> .plt, and the .plt entries involved are all the size size? If so, ld
> can ensure that all such .plt entries are adjacent and emit two new
> tags giving the array location and size.
Once again with the special handling. This isn't faster.
Aside from that, unknown DT_* flags are no fatal errors at program
loading time. Unknown relocations are. The result is that with your
proposal people running new binaries on old systems will see mysterious
crashes or worse, strange results. With new relocations they will see a
useful error message and predictable behavior.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoem4cACgkQ2ijCOnn/RHRdkwCggAql//ieDFxEkq77qvh8VE1U
NGQAniqeY1BD08SsHSqJpGHCrU1Iqe7Y
=SAav
-----END PGP SIGNATURE-----
H.J. Lu
>> Is it true that the new IRELATIVE relocation should only appear in
>> .plt, and the .plt entries involved are all the size size? If so, ld
>> can ensure that all such .plt entries are adjacent and emit two new
>> tags giving the array location and size.
>
> Once again with the special handling. This isn't faster.
>
> Aside from that, unknown DT_* flags are no fatal errors at program
> loading time. Unknown relocations are. The result is that with your
> proposal people running new binaries on old systems will see mysterious
> crashes or worse, strange results. With new relocations they will see a
> useful error message and predictable behavior.
>
Good point. I have
static inline void
__attribute ((always_inline))
elf_machine_irela (const Elf64_Rela *reloc)
{
Elf64_Addr *const reloc_addr = (void *) reloc->r_offset;
const unsigned long int r_type = ELF64_R_TYPE (reloc->r_info);
if (__builtin_expect (r_type == R_X86_64_IRELATIVE, 1))
{
Elf64_Addr value = reloc->r_addend;
value = ((Elf64_Addr (*) (void)) value) ();
*reloc_addr = value;
}
}
for static executables. It is called from elf-init.c. How can I
report a bad relocation safetly?
--
H.J.
Ulrich Drepper
Hash: SHA1
H.J. Lu wrote:
> static inline void
> __attribute ((always_inline))
> elf_machine_irela (const Elf64_Rela *reloc)
> {
> Elf64_Addr *const reloc_addr = (void *) reloc->r_offset;
> const unsigned long int r_type = ELF64_R_TYPE (reloc->r_info);
>
> if (__builtin_expect (r_type == R_X86_64_IRELATIVE, 1))
> {
> Elf64_Addr value = reloc->r_addend;
> value = ((Elf64_Addr (*) (void)) value) ();
> *reloc_addr = value;
> }
> }
>
> for static executables. It is called from elf-init.c. How can I
> report a bad relocation safetly?
In this specific case, fail on anything but the R_*_IRELATIVE
relocation. Should there be in future another relocation which has to
be handled even in static executables then it'll get it's own 'else if'
branch. You don't have to copy into the static executable any
relocation except those really needed.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoenjsACgkQ2ijCOnn/RHT1bgCgtflclvCisZ2PxG9qAEPRDGS7
oaAAnRaPILPvOI/x48vA8h6VekTgn1p0
=+bet
-----END PGP SIGNATURE-----
Ulrich Drepper
Hash: SHA1
H.J. Lu wrote:
> for static executables. It is called from elf-init.c. How can I
> report a bad relocation safetly?
[I assume you meant dl-init.c.]
And for sake of reducing strange effects: it would be best to to handle
this a bit different. Implicitly relying on the programmer having a
newer glibc installed which using ifunc can cause problems. If,
instead, you write a new code fragment which is placed into the .init
section (provided by the linker whenever ifunc symbols are used in
statically linked code), then this new init function could reference a
function in libc which doesn't exist in older versions.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoen3cACgkQ2ijCOnn/RHRmOgCeM6xpmcY3WEqxU28YbzSWDWB8
hf4AniMyukXNOgaxZXkztBVWBPVDi5oH
=Y9Gf
-----END PGP SIGNATURE-----
H.J. Lu
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> H.J. Lu wrote:
>> for static executables. It is called from elf-init.c. How can I
>> report a bad relocation safetly?
>
> [I assume you meant dl-init.c.]
No, it is in elf-init.c.. The R_*_IRELATIVE relocations are
processed first in __libc_csu_init before preinit_array only
for static executables.
> And for sake of reducing strange effects: it would be best to to handle
> this a bit different. Implicitly relying on the programmer having a
> newer glibc installed which using ifunc can cause problems. If,
> instead, you write a new code fragment which is placed into the .init
> section (provided by the linker whenever ifunc symbols are used in
> statically linked code), then this new init function could reference a
> function in libc which doesn't exist in older versions.
>
The same can be said for XXX_array. I don't think you will
get an error if you use preinit_array and your glibc doesn't support
it.
--
H.J.
Ulrich Drepper
This might be, but it doesn't mean we should repeat mistakes.
But I don't really care much. Nobody should link statically in the
first place. I wouldn't even care to implement IFUNC for static linking.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoeo88ACgkQ2ijCOnn/RHQAawCeJLdhzhbkY+lkZEHIrmAk20qH
kfQAnjzkCL6Q+cgUGygJK2nX5E63qPr3
=5Pnb
-----END PGP SIGNATURE-----
H.J. Lu
Here is the current proposal implemented in the Linux binutils
2.19.51.0.7.
H.J.
---
STT_GNU_IFUNC
R_*_IRELATIVE
All references to a STT_GNU_IFUNC symbol, including function call and
function pointer, will go through a PLT slot, which jumps to the address
stored in the GOT entry. If the STT_GNU_IFUNC symbol is locally defined,
a R_*_IRELATIVE relocation will be applied to the GOT entry at load time.
Otherwise, dynamic linker will lookup the symbol at the first call to the
function and update the GOT entry. This applies to all usages of
STT_GNU_IFUNC symbols in shared library, dynamic executable and static
executable.
Roland McGrath
entry-point that returns the function pointer. Is it "the prevailing
normal ABI" for a function of no arguments returning a pointer to function?
i.e., with whatever call-clobbered registers et al that generically entails.
Or is it a special-case ABI to be defined precisely in the
processor-specific spec? However much or little the specification of the
ELF feature per se wants to say about this, it should be explicit about
what it does or doesn't specify for it.
Thanks,
Roland
Ian Lance Taylor
> 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.
How is the "corresponding R_*_RELATIVE relocation" determined?
Ian
H.J. Lu
I added "as specified in the processor-specific ABI":
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 as
specified in the processor-specific ABI.
--
H.J.
H.J. Lu
How about this:
The calling convention of the STT_GNU_IFUNC function, which takes no
arguments and returns a function pointer, should follow the
processor-specific ABI. All rules for caller-saved and callee-saved
registers apply.
--
H.J.
H.J. Lu
I added "as specified in the processor-specific ABI":
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
Ian Lance Taylor
> 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.
How is the "corresponding R_*_RELATIVE relocation" determined?
Ian
H.J. Lu
There is an issue with STT_GNU_IFUNC symbols.
For branch, it is easy to understand. But it is unclear what the value
of STT_GNU_IFUNC symbol should be. In a non-shared object, the value
of the undefined STT_GNU_IFUNC symbol is the address of the PLT entry
since it will only be resolved at run-time. In a shared object,
the value of the STT_GNU_IFUNC symbol will be the address of the
real function. We can't use the address of the PLT entry since
the PLT entry in a shared object may not be usable in non-shared object.
So the undefined STT_GNU_IFUNC symbol will have 2 different values.
Will it be a problem?
--
H.J.
H.J. Lu
There is an issue with STT_GNU_IFUNC symbols.
Ulrich Drepper
Hash: SHA1
H.J. Lu wrote:
> For branch, it is easy to understand. But it is unclear what the value
> of STT_GNU_IFUNC symbol should be. In a non-shared object, the value
> of the undefined STT_GNU_IFUNC symbol is the address of the PLT entry
> since it will only be resolved at run-time.
What undefined STT_GNU_IFUNC symbol? The whole point of this symbol
type is that the caller doesn't have to care at all about the
optimizations. A library author can introduce them in DSOs and programs
at the next start can take advantage of this.
Linking against an STT_GNU_IFUNC symbol in a DSO should create a normal
STT_FUNC symbol table entry for the undefined symbol.
Again, there are no undefined STT_GNU_IFUNC symbols.
> So the undefined STT_GNU_IFUNC symbol will have 2 different values.
> Will it be a problem?
See above. If you linker patch creates undefined STT_GNU_IFUNC symbols,
take that code out. That's the solution.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoorHkACgkQ2ijCOnn/RHSeHgCgtQgNxr3/FcEsGiMw2ZshnblY
1fwAoJo0zfcPBrzqHYR2EBuxBaZCA5mO
=dnZJ
-----END PGP SIGNATURE-----
Ulrich Drepper
Hash: SHA1
H.J. Lu wrote:
> For branch, it is easy to understand. But it is unclear what the value
> of STT_GNU_IFUNC symbol should be. In a non-shared object, the value
> of the undefined STT_GNU_IFUNC symbol is the address of the PLT entry
> since it will only be resolved at run-time.
What undefined STT_GNU_IFUNC symbol? The whole point of this symbol
type is that the caller doesn't have to care at all about the
optimizations. A library author can introduce them in DSOs and programs
at the next start can take advantage of this.
Linking against an STT_GNU_IFUNC symbol in a DSO should create a normal
STT_FUNC symbol table entry for the undefined symbol.
Again, there are no undefined STT_GNU_IFUNC symbols.
> So the undefined STT_GNU_IFUNC symbol will have 2 different values.
> Will it be a problem?
See above. If you linker patch creates undefined STT_GNU_IFUNC symbols,
H.J. Lu
There is an ordering issue on STT_GNU_IFUNC functions. In shared object,
we need dynamic relocation to get the real function address when there is a
non-GOT reference against a STT_GNU_IFUNC symbols. A STT_GNU_IFUNC
function may use some data which need to be relocated first. Possible solutions:
1. A STT_GNU_IFUNC function should never access any data which need
relocation. Or
2. Dynamic relocations against STT_GNU_INFUNC symbols should be
placed after all other relocations.
Any comments?
Thanks.
H.J.
H.J. Lu
Roland McGrath
> relocation.
This does not seem like too much of a constraint, given that it also
unavoidably has to work before the DSO's initializers have run.
i.e., it is always special-purpose code that has to be written very
carefully. Being PIC code it should not be relying on much to have been
done before. It just has to avoid any PLT calls or other GOT use itself.
> 2. Dynamic relocations against STT_GNU_INFUNC symbols should be
> placed after all other relocations.
This is not possible, is it? Some DSO has a reference to "&strlen".
It has no idea that libc's definition will be STT_GNU_IFUNC.
The DSO might even have been linked against a libc.so that did
not use STT_GNU_IFUNC to define "strlen".
The only other alternative to #1 that I see is some scheme whereby "&func"
will in all cases resolve to a PLT entry rather than the actual
STT_GNU_IFUNC symbol's st_value. i.e., the ifunc resolver is only called
for PLT resolution (and you can do all those last for BIND_NOW).
e.g. in the defining DSO make ld generate a PLT entry with second symbol a
la executables' PLT entries, and then have rtld ignore the STT_GNU_IFUNC
symbol when resolving non-PLT relocs. (Seems highly dubious.)
But in fact any scheme with that result might be undesireable in practice.
If the executable does not refer to "&func", then we don't have the pointer
equality issue and so DSOs with function pointer tables pointing to other
DSOs' entry points would do the extra indirection of a PLT jump when it
could be avoided except for this initialization order question.
Thanks,
Roland
H.J. Lu
This patch implements #2. It may not solve all the problems. But it
works for my simple testcase.
--
H.J.
----
bfd/
2009-06-06 H.J. Lu <hongj...@intel.com>
* elf32-i386.c (elf_i386_link_hash_table): Add irelifunc.
(elf_i386_link_hash_table_create): Initialize irelifunc.
(elf_i386_check_relocs): Updated. Set up irelifunc for
shared objects.
(elf_i386_allocate_dynrelocs): Use irelifunc for dynamic
relocation for non-GOT reference of STT_GNU_IFUNC symbol in
shared objects.
(elf_i386_relocate_section): Likewise.
* elf64-x86-64.c (elf64_x86_64_link_hash_table): Add irelifunc.
(elf64_x86_64_link_hash_table_create): Initialize irelifunc.
(elf64_x86_64_check_relocs): Updated. Set up irelifunc for
shared objects.
(elf64_x86_64_allocate_dynrelocs): Use irelifunc for dynamic
relocation for non-GOT reference of STT_GNU_IFUNC symbol in
shared objects.
(elf64_x86_64_relocate_section): Likewise.
* elf-bfd.h (_bfd_elf_create_static_ifunc_sections): Renamed to
...
(_bfd_elf_create_ifunc_sections): This.
* elflink.c (_bfd_elf_create_static_ifunc_sections): Renamd to
...
(_bfd_elf_create_ifunc_sections): This. Create .rel[a].ifunc
for shared objects.
ld/
2009-06-06 H.J. Lu <hongj...@intel.com>
* scripttempl/elf.sc: Add .rel.ifunc and .rela.ifunc.
H.J. Lu
>> The only other alternative to #1 that I see is some scheme whereby "&func"
>> will in all cases resolve to a PLT entry rather than the actual
>> STT_GNU_IFUNC symbol's st_value. i.e., the ifunc resolver is only called
>> for PLT resolution (and you can do all those last for BIND_NOW).
>
>
Please try the current binutils in CVS. I think I have fixed all
problems. If not,
please open a bug report with a testcase.
Thanks.
--
H.J.
Roland McGrath
> > will in all cases resolve to a PLT entry rather than the actual
> > STT_GNU_IFUNC symbol's st_value. i.e., the ifunc resolver is only called
> > for PLT resolution (and you can do all those last for BIND_NOW).
>
You seem to have misunderstood the idea.
Roland McGrath
> > will in all cases resolve to a PLT entry rather than the actual
> > STT_GNU_IFUNC symbol's st_value. i.e., the ifunc resolver is only called
> > for PLT resolution (and you can do all those last for BIND_NOW).
>