[Mips}Using DT tags for handling local ifuncs

[Richard Sandiford]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> 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?

Yeah, this is GGA_NORMAL vs. GGA_RELOC_ONLY in elfxx-mips.cs

>  Also let's make sure old ld.so binaries fail in a sensible way with ifunc 
> binaries though, i.e. no segfault or suchlike.

I agree it's worth checking, but in this case it should do, because we'll
only be using the new area for R_MIPS_IRELATIVE, which is a new relocation
type.  ld.so does complain about types it doesn't understand.

>> >  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.

OK, once we start using the new GOT region then I agree we can make
that the case.  In terms of the ABI and patch as posted though, we used
IPLTs for all ifuncs defined in executables:

  Dynamically linked executables with ifunc definitions are for the most
  part the same as static executables, with the following exceptions:

    *) No __rel_iplt_start/end symbols. The dynamic linker handles dynamic
       relocations.
    *) Generate STT_GNU_IFUNC symbols in the .dynsym section with the value
       being the iplt entry for this IFUNC and transform them into 
       STT_FUNC symbols. Any references to this IFUNC have to go through 
       the stub. The dynamic linker (ld.so) will be doing the fixup at start-
       up.

Thanks,
Richard