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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jack Carter <Jack.Carter@imgtec.com> writes:
>> > I am not convinced that I am on the same wave length with you guys yet,
>> > so is the
>> > following what you had in mind?
>> >
>> > I believe the local GOT is to be segmented with a implicit and explicit
>> > region. The implicit
>> > region will behave as it does today and just add the load time
>> > offset. The explicit region will
>> > be fixed up through the relocation table process.
>> >
>> > There will be a dynamic tag that points to the offset of the explicitly
>> > relocated local GOT.
>> > It can't be DT_MIPS_LOCAL_GOTIDX because that refers to entries with symbols
>> > associated with them so I am assuming that a new tag needs to be defined
>> > (DT_MIPS_LOCAL_EXPLICIT?).
>> 
>> I was thinking of doing it the other way around and putting the
>> explicitly-relocated region first.
>
> This  would cause more ripples because it changes the current assumption
> of where implicit local GOT begins and where the global GOT begins. See
> my diatribe
> about DT_MIPS_LOCAL_GOTNO below.

I disagree, also below.

>> At the moment, the implicitly-relocated region starts at 1 or 2,
>> depending on whether the top bit of entry 0 is set.  We'd have
>> a new tag (like you say) to specify explicitly the start of the
>> implicitly-relocated local GOT.
>> 
>> FWIW, I don't really see the explicitly-relocated region as being
>> part of the local GOT.  It's a new region separate from both the
>> local and the global GOTs.  
>
> This is a semantic issue. These entries are currently considered local. Either
> way we are making a logical partitioning of the GOT no matter how you look
> at it. We will need a name for the partitions eventually since I will be
> writing
> up this part of the abi to get into a revised version and will want everyone to
> be discussing the same thing ;-)

Names aren't my forte, but I'd like something that means "explicitly-relocated
GOT", only pithier.  I'll call it ER GOT below though.

> DT_MIPS_LOCAL_GOTNO is a count, not an index. If one doesn't want
> to include both the implicit and explicit partitions in this count then
> it affects
> how we locate both the local and global areas. If we assume both implicit and
> explicit are local and make up DT_MIPS_LOCAL_GOTNO then the current
> assumptions stay in place.

Whether DT_MIPS_LOCAL_GOTNO is a count or an index is a semantic issue too.
If it's a count, it counts from the start of the GOT, so includes the
reserved entries at the beginning of the GOT as well as the local GOT
entries themselves.

Whichever way you look at it, the implicitly-relocated local GOT stops
at index DT_MIPS_LOCAL_GOTNO.  What I'm proposing wouldn't change that.
DT_MIPS_LOCAL_GOTNO isn't the number of entries that get R_MIPS_REL* treatment.

>> I think it would be fine to have explicit
>> relocations against global symbols here too in future, if the usual
>> R_MIPS_{32,64} isn't what we want for some reason.
>
> Fine, but we will probably need to make sure they follow the symbol to GOT
> entry rules. That is why SGI had them in the global GOT partition. This will
> mean that it would be best to have the explicit partition second so it can be 
> sequenced naturally with the global symbols along with the global GOT.

I don't follow.  The global GOT has to be handled before processing
the relocations (and of course the relocations against the GOT would
follow the same rules as other dynamic relocations, like you say).
If the ifunc region comes between the local GOT and the global GOT
then the layout would be:

   local GOT
   ER GOT
   global GOT

but the processing order would be:

   local GOT
   global GOT
   .rel.dyn (including ER GOT)

I don't see why having ER GOT after the local GOT is more logical than
having it first from this point of view.  And the advantage of having it
first is (d) from my earlier message.

If you think the ER region should come after the global GOT too, as in:

   local GOT
   global GOT
   ER GOT

then as I mentioned in the earlier message, that's what we already do
for TLS relocs.  The drawback is that the global GOT has to contain all
symbols that have a relocation against them, even if there are no
GOT references to those symbols.  And things like vtables mean that
such symbols can be quite common in C++ objects.

So the ER entries might then be out of range of $gp (and so require
multigot) even though the number of GOT entries that are accessed
$gp-relative is small enough for a single GOT.

Thanks,
Richard