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

[Jack Carter <Jack dot Carter at imgtec dot com>]

I'm trying to catch up on Mips binutils multigot and glibc GOT behavior to
match this discussion.


On 12/14/2013 02:06 AM, Richard Sandiford wrote:> "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.

I am missing this part of the ABI. If a symbol has a relocation against it why does
it have to be in the GOT? TLS symbols that are referenced through the PLT are 
specified to be in the GOT, but otherwise?

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

I don't understand this either. Local GOT and global GOT both are GP relative.
Don't you have to include both along with any other GP relative section in the
multigot accounting? And if so, don't you have to include pieces of both the local
and global GOT in each multigot region that needs it?

In my mind it shouldn't matter where you put a GOT entry in terms of multigot 
threshold accounting.

Is there a way that I can reduce the multigot threshold in binutils for testing purposes?

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

Is there no versioning or features list that is currently checked? How do you currently
deal with forward incompatibility in ld.so?

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

The full 64 bit address for mips64 is there because the system I test on (Cavium-Octeon) 
defaults at a high address. I had originally coded for only the lower 32 bits and hit this 
immediately. Beyond that, I have no problem with different encodings. I just mimicked 
what was being done in other stubs.

.................

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

If the dso LOCAL/INTERNAL/HIDDEN IIfunc GOT entry has a symbol associated with it, 
it does not need to go through an iplt stub since the call is referenced through the GOT
value which will be fixed up by ld.so.

The only time I would see a dso defined ifunc call going through the iplt is for local calls that
go through the local got offset table. That is, the offset in the GOT is shared among multiple
addresses and the call needs an additional addend to get the final address. Does this occur 
for function calls in GCC/binutils or do all function addresses get their own GOT entry?

Getting back to using dynsym symbols:

But symbol lookups are expensive. That is why we have implicit fixups in the GOT. If we are 
going to sequester these "local" ifunc entries in their own GOT partition, why make them look
up a symbol? Have the partition be an DT_MIPS_IFUNC_OFFSET and 
DT_MIPS_IFUNC_NUM delimited area and just add the runtime dso offset and run the resolver
on the address stored in the GOT entry. We can even embed it in the current LOCAL got region
and let the dso offset part happen as it is now and go back and run the resolvers for the final
fixup.

This does not preclude a future region for explicit relocations. 

Thanks,

Jack