public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Jack Carter <Jack.Carter@imgtec.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: "libc-ports@sourceware.org" <libc-ports@sourceware.org>
Subject: RE: [RFC][PATCH] MIPS ifunc for glibc
Date: Tue, 20 Aug 2013 00:38:00 -0000	[thread overview]
Message-ID: <4CEFBC1BE64A8048869F799EF2D2EEEE01AAEA08@BADAG02.ba.imgtec.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1308182031510.10353@digraph.polyomino.org.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

  reply	other threads:[~2013-08-20  0:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-17  0:31 Jack Carter
2013-08-18 20:39 ` Joseph S. Myers
2013-08-20  0:38   ` Jack Carter [this message]
2013-08-20 14:03     ` Joseph S. Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CEFBC1BE64A8048869F799EF2D2EEEE01AAEA08@BADAG02.ba.imgtec.org \
    --to=jack.carter@imgtec.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-ports@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).