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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jack Carter <Jack.Carter@imgtec.com> writes:
>> OTOH, the same problem applied when TLS was added: the TLS GOT entries
>> needed to be explicitly relocated.  What happened then was that the
>> entries were added after the global GOT.  I suppose that avoided the
>> new tag, but the disadvantage is that it can force multi-GOTs to be
>> used unnecessarily.  Especially since the global GOT needs to contain
>> all symbols that have relocations against them, even if there are no
>> GOT accesses to them.  But I could live with irelative relocations
>> being handled this way too if you prefer.
>
> Unless we go the route of SGI and associate the GOT entries with dynamic
> symbols,
> we should just continue to treat these as true locals and keep them in the local
> GOT. To do otherwise at this point would be just gratuitous and like you said,
> trip multigot more often.

The same problem would apply to ifuncs that are STB_LOCAL in the
input .o (functions declared as static in C).  I don't think we'd want
to be create dynsyms for symbols that were never global to begin with.

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

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

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