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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jack Carter <Jack.Carter@imgtec.com> writes:
> Richard,
>
> Unless this last argument below can convince you or at least give you
> pause to consider "implicit, explicit, default" ordering, I will start
> on "explicit, implicit, default".
>
> I don't think it is the "right" thing to do, but what the heck, what
> is right and wrong anyway? What you are proposing should be
> workable. I just need to get it correctly written up before shipping.
>
> Let me know and I will start coding,
>
> Jack
>
>> > 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.
>
> Maybe I should clarify that I am trying to follow this in the 64-bit
> ELF Object File Specification. That may be an issue.
>
> As defined in the document: "DT_MIPS_LOCAL_GOTNO:This member contains the
> number of local GOT entries.". So it is a count of locals.

I think you're missing my point.  Entry 0 in the GOT is the dynamic
resolver routine, part of the dynamic linker.  With the GNU extension,
entry 1 points the link map.  I don't think it makes sense to say that
either of these entries are "local" to the DSO since they both point to
data outside the DSO's image.

These entries are different from the rest of the local GOT in two
important ways:

- The dynamic linker must always set up the first two entries,
  even for ET_EXECs.  But it does not need to process the local
  GOT entries for ET_EXECs.

- The dynamic linker does not simply add the "base address" to these
  first two entries.  It stores other data there instead.

So the number of entries that are processed as locals is
DT_MIPS_LOCAL_GOTNO - (1 or 2), not DT_MIPS_LOCAL_GOTNO.

> According to the same document: the local table "consists of local GOT
> addresses, i.e.  non-preemptible (protected) addresses defined within
> the executable/DSO."

But it also includes the dynamic resolver routine, if you really insist
that the local area starts at entry 0.  And with the GNU extension,
the link map in entry 1 too.  Neither of those are defined within
the executable or DSO.

>>> 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)
>
> So what? It doesn't matter what the order is for processing. The
> locations matter if we think that we might want to tap into the dynsym
> table later.

Why would we tap into the dynsym though?  The whole point is that this
area is relocated normally - it isn't tied to the dynsym in the way that
the global GOT area is.  The explicitly-relocated area is just another
part of the DSO image that can be relocated using .rel.dyn.

>> 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.
>
> You're right about d.
>
> It is more logical to me because that is the way it use to be with SGI
> I suppose and you brought up the notion you may want to do that in the
> future - Symbol associated Internal, and Hidden got entries.

No, the internal and hidden entries was the notion you brought up. :-)
(d) was about something else entirely: the possiblity that we might need
to have a third "special" entry at the start of the GOT in future,
on top of the two special ones that we already have.

TBH I don't see any point in having internal and hidden entries in .dynsym.
Once we know the thing binds locally we should just use base-relative
relocations for it.  (Including the implicit base-relative relocations
applied to the local GOT.)

Of course it's good to keep internal and hidden symbols in .symtab for
dumping purposes, but we already do that.

Thanks,
Richard