This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH]: Sparc STT_GNU_IFUNC support
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: binutils at sourceware dot org, jakub at redhat dot com, amodra at gmail dot com, hongjiu dot lu at intel dot com
- Date: Fri, 5 Feb 2010 16:02:32 -0800
- Subject: Re: [PATCH]: Sparc STT_GNU_IFUNC support
- References: <email@example.com>
On Fri, Feb 5, 2010 at 3:42 PM, David Miller <firstname.lastname@example.org> wrote:
> I have a GLIBC implementation as well which I am still refining
> but the current patch is at:
> ? ? ? ?http://vger.kernel.org/~davem/sparc_glibc_ifunc.diff
> All ifunc test cases in binutils pass with these changes.
> All ifunc test cases in glibc pass except ifuncmain6pie, fixing that
> will require adding GOTDATA_OP support to gcc and binutils which I do
> plan to work on.
> I fully tested both 64-bit and 32-bit.
> ifuncmain6pie fails because it is a case where a shared library has a
> relocation to an ifunc symbol, which is satisfied by a PIE executable.
> The IFUNC resolving function in the PIE executable generates
> relocations for the local symbol references to return the selected
> function pointer. ?ie. something like:
> static int one(void)
> ?return 1;
> void *foo_ifunc(void)
> ?return &one;
> results in an R_SPARC_RELATIVE relocation against the GOT
> for "one".
> So depending upon the order in which the dynamic linker processes
> relocations, the IFUNC function might get called before the
> relocations within it are resolved.
> i386 does not have this problem because it uses @GOTOFF for local
> symbols referenced in PIC code. ?Sparc's GOTDATA_OP will work
> just like this, allowing us to do local symbol references in
> PIC code without any dynamic relocations.
> I think powerpc64 will hit this failure too, because what should
> happen is we end up with a TOC for the PIC code, and a bunch
> of R_POWERPC_RELATIVE relocations. ?Alan, does ifuncmain6pie
> pass on powerpc64?
> Implementation wise I took the same approach H. J. Liu took on i386,
My last name is Lu, not Liu :-(.
> using a seperate hash table for handling local IFUNC symbols.
> Everything, including emitting PLT entries, essentially "just works"
> by running allocate_dynrelocs() over this new local hash table.
> This depends upon "[PATCH]: Sparc BFD cleanups and fixes."
> Ok to commit?
You may use some functions in elf-ifunc.c.