This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Mips}Using DT tags for handling local ifuncs
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Jack Carter <Jack dot Carter at imgtec dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Sat, 14 Dec 2013 01:28:06 +0000
- Subject: Re: [Mips}Using DT tags for handling local ifuncs
- Authentication-results: sourceware.org; auth=none
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DDC0F at BADAG02 dot ba dot imgtec dot org> <87r49p9dit dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1312092333190 dot 19368 at tp dot orcam dot me dot uk> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DDFC3 at BADAG02 dot ba dot imgtec dot org> <87ob4p6qdt dot fsf at talisman dot default> <87k3fd6owc dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE23E at BADAG02 dot ba dot imgtec dot org> <87txef6a07 dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE3B8 at BADAG02 dot ba dot imgtec dot org> <87haaf5hbg dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE50C at BADAG02 dot ba dot imgtec dot org> <877gbb5c2k dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE59A at BADAG02 dot ba dot imgtec dot org> <alpine dot DEB dot 1 dot 10 dot 1312112311480 dot 19368 at tp dot orcam dot me dot uk> <87y53q4czx dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1312121406040 dot 19368 at tp dot orcam dot me dot uk> <87ppp14wr7 dot fsf at talisman dot default>
On Thu, 12 Dec 2013, Richard Sandiford wrote:
> > Hmm, thanks for reminding me that, that rules out the space before the
> > ABI GOT. We still have space afterwards for things like this (or e.g. for
> > a small-data area if we ever implement it) though.
>
> Yeah, putting it afterwards is what we already do for TLS relocs.
> The problem with that is that the ABI global GOT has to include all
> symbols that have a relocation against them, even if there's no need
> for a $gp-relative GOT access. And there can be quite a lot of symbols
> like that, especially for things like vtables in C++ code.
>
> So if we put the relocations after the ABI GOT we would end up forcing
> the use of multigots even though the number of "real" GOT entries
> (those that need to be accessed $gp-relative) is small enough for
> a single GOT. The idea of the tag is to avoid that.
I see, that makes sense to me. Do we already care to sort GOT entries
appropriately?
Also let's make sure old ld.so binaries fail in a sensible way with ifunc
binaries though, i.e. no segfault or suchlike.
> > Fair enough, but then, after a bit of thinking, do we need
> > %highest/%higher stuff in the first place? For n64 non-PIC PLT is only
> > supported for msym32 binaries anyway and it doesn't look to me it is ever
> > going to change, so the high 33 address bits will always be zero and the
> > 32-bit version (with LD rather than LW) will do, and for SVR4 PIC binaries
> > you need to figure out the GOT pointer from $t9 instead (is there any
> > point in making a difference between ET_EXEC and ET_DYN binaries here?);
> > note that this would exclude ifunc calls from being tail calls (breaking
> > the standard calling convention) so it looks to me we'll have to make an
> > extra stub to load $gp beforehand.
> >
> > Have I missed anything?
>
> One of the main reasons for requiring -msym32 for PLTs is that absolute
> code is only really interesting if you can use %hi and %lo to access symbols.
> If you need the full %highest/... sequence then it's often better to use
> a GOT instead.
>
> But despite the name, IPLTs are different. They are used regardless of
> whether the input is new-style absolute code or SVR4 PIC. ifuncs in
> themselves shouldn't force -msym32.
Of course they shouldn't *force* -msym32 -- what I mean is the absolute
sequence is only applicable for PLT executables, that imply one of -32,
-n32 or -msym32 already. For shared libraries an absolute sequence is
useless as they're relocated at the load time so only offsets from PC (or
GP, once that's been figured out) can be used. So we'd have to come with
a different sequence anyway.
For executables using traditional SVR4 PIC code we could use the absolute
sequence indeed. However I checked the ifunc ABI description again and no
lazy binding is proposed for ifuncs so no stub of any kind will be
required for PIC code (be it an executables or a shared library) as all
calls are made through the GOT there anyway and this will have been
relocated by the time any ifunc call is reached.
So I stand by my assertion that no %highest/%higher stuff is required.
If you think I'm wrong, then can you please give me a counter example?
Maciej