Re: [Mips}Using DT tags for handling local ifuncs

["Maciej W. Rozycki" <macro at codesourcery dot com>]

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