This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE
- From: Ulrich Drepper <drepper at redhat dot com>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Generic System V Application Binary Interface <generic-abi at googlegroups dot com>, IA32 System V Application Binary Interface <ia32-abi at googlegroups dot com>, Nick Clifton <nickc at redhat dot com>, Binutils <binutils at sourceware dot org>, GNU C Library <libc-alpha at sourceware dot org>, discuss at x86-64 dot org
- Date: Tue, 26 May 2009 07:33:34 -0700
- Subject: Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE
- References: <6dc9ffc80905251156p1ab274aey8e52be086fd88749@mail.gmail.com> <4A1BADCA02000078000027BB@vpn.id2.novell.com>
-----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-----