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

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

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

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

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

Unless we want a separate rule and or sorting for non-global symbols that follow
the dynsym table along with another tag (DT_MIPS_LOCAL_GOTSYM?) pointing
to it. Which is workable, but I don't think should be necessary if the explicit partition
follows the implicit.

> 
> So...
> 
> > The current loop in the dynamic linker will go from the beginning of
> > the local GOT to just before the explicit local GOT start. It would be
> > tempting to apply the diff to all the local GOT since the ifunc will
> > have to do that too, but that may well hinder future relocation
> > options.
> 
> ...I was suggesting that the loop should change the start index
> rather than the end index.  See the glibc change I sketched out upthread.
> 
> But yeah, apart from swapping the explicit and implicit regions,
> that was what I had in mind.
> 
> > The static linker will have to segregate the explicit local GOT
> > entries from the implicit local GOT entries with the explicit
> > following the implicit. They will together make up
> > DT_MIPS_LOCAL_GOTNO.
> 
> Yeah, DT_MIPS_LOCAL_GOTNO would still be the end of the implicitly-relocated
> local GOT and start of the implicitly-relocated global GOT.
> 
> Thanks,
Richard
> 

BTW, I can go either way, it just seems more natural to have this third logical partition
after the implicit one to me.

Cheers,
Jack