This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
RE: [RFC][PATCH] MIPS ifunc for glibc
- From: Jack Carter <Jack dot Carter at imgtec dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "libc-ports at sourceware dot org" <libc-ports at sourceware dot org>
- Date: Tue, 20 Aug 2013 00:37:15 +0000
- Subject: RE: [RFC][PATCH] MIPS ifunc for glibc
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE01AAE1FA at BADAG02 dot ba dot imgtec dot org>,<Pine dot LNX dot 4 dot 64 dot 1308182031510 dot 10353 at digraph dot polyomino dot org dot uk>
Joseph,
Good comments. See inline.
Thanks for looking at this!
Jack
________________________________________
From: Joseph Myers [joseph@codesourcery.com]
Sent: Sunday, August 18, 2013 1:38 PM
To: Jack Carter
Cc: libc-ports@sourceware.org
Subject: Re: [RFC][PATCH] MIPS ifunc for glibc
On Sat, 17 Aug 2013, Jack Carter wrote:
> > This is the initial MIPS ifunc patch for glibc. This patch should be
> > applied in conjunction with the binutils patch.
>
> Do you have an ABI document specifying all the relevant semantics, for all
> three ABIs?
All three abis, o32, n32, 64 should behave the same. I have only tested o32 and thus this patch just vouches for that abi. The others were to follow in subsequent patches. This is what I had in the accompanying binutils patch:
All ifunc functions are represented in .iplt section stubs and
in the .igot.plt section table. Each igot.plt entry has an
R_MIPS_IRELOCATE relocation record against it with the initial
igot entry having link time address of the ifunc routine and
after the relocation action, the final runtime target routine
address.
The only change to the traditional MIPS GOT was to use the .iplt stub
address for the defined ifunc function instead of the function address.
This should allow seamless multigot support
***************************************
If an iplt is needed:
Generate iplt stubs (.iplt)
Generate igot table (.igot.plt)
Generate IRELATIVE relocations for igot
Iplts are needed for a.outs only.
Non-shared a.outs:
Always goes through the iplt with IRELATIVE relocations against
the igot.
Shared a.outs (both fPIC and not):
All a.out references are direct with got entries containing ifunc
addresses that have IRELATIVE relocations against them. The dynamic
linker will catch the IRELATIVE relocations and do the fixup based on
the GOT contents
Dso references are through the iplt with IRELATIVE relocations
against the igot and the dynsym entries being the iplt address
and the symbol type changed STT_FUNC. The dynamic linker will update
the igot table in the a.out in the same manner as it does the GOT.
Dsos:
No iplt, igot or IRELATIVE relocations.
The GOT and .dynsym will have the ifunc values and the dynsym type
will remain STT_GNU_IFUNC. The dynamic linker will detect that
the symbol is an STT_GNU_IFUNC and do the fixup based on the defining
dynsym address.
In all cases the contents of the igot is the ifunc address with an
R_MIPS_IRELATIVE relocation against it.
In all cases the contents of the got for the ifunc functions are the ifunc
addresses.
***************************************
Is this enough? If not, could you point me to an example I could model after?
> Why aren't you consistently passing the HWCAP value to resolver functions
> (it seems some places pass it but others don't)? If you don't pass it
> from the start, it could be problematic to change the ABI later to start
> passing it, as applications' IFUNC resolvers wouldn't know if they are
> being run with a glibc version that passes the HWCAP value to them or not.
> The ABI document should presumably specify what arguments get passed to
> the resolver function....
I am not sure what you mean by passing the HWCAP value to the resolver. The resolver contains logic that determines the HWCAP and from that picks the actual function that is most appropriate for the hardware being run on, returning the address to said function.
Does the rough ABI I gave above answer your question?
If I missed any conditions, could you be specific?
> > + case R_MIPS_IRELATIVE:
> > + {
> > + ElfW(Addr) value;
> > +
> > + /* The address for the got entry storing the address for the */
> > + /* ifunc routine is in this relocation. To get the address of */
> > + /* the function to use on this machine the ifunc routine is run */
> > + /* and its return value is the address which is then put back */
> > + /* into the got entry. */
> Ordinary multi-line comment, please.
This was just missed. Thanks for catching it.
--
Joseph S. Myers
joseph@codesourcery.com