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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jack Carter <Jack.Carter@imgtec.com> writes:
> Too bad we are not in the same room. I keep reading that I am not
> understanding stuff that I understand and visa versa ;-)

Don't think I accussed you of not understand things :-)
I just thought that you were saying that:

(A)
> 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.

and:

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

together meant that there are DT_MIPS_LOCAL_GOTNO local GOT entries,
all pointing to "non-preemptible (protected) addresses defined within
the executable/DSO".  But that was never the case, even in the original
32-bit psABI.  The GOT has always started with entries that didn't
fit the description in (B), even though those entries are included
in DT_MIPS_LOCAL_GOTNO.  (At first it was just the dynamic resolver.
The GNU extension added the link map too.)  So I don't feel too guilty
about adding even more entries of this type.

> Is it fair to say that i can start on the reserved entries (3?),
> explicit non-preemptable,
> implicit non-preemptable, global-preemptable. Or are there still
> apparent issues?

It's 2 reserved entries at the moment (we're not changing that here).
What I meant in (d) was that, by having the tag to specify the index
of the first implicitly-relocated GOT entry, it would be possible to
reserve more entries in future, if the need arose.  We wouldn't need
it for ifuncs, but we might for some future feature.

The other point I was trying to make is that I don't think we should
view the new area as "explicit non-preemptable".  It's "explicitly-
relocated" full stop.  It would be perfectly valid to have relocations
against global preemptable symbols in there too, if a normal R_MIPS_{32,64}
relocation wasn't what we wanted.

I.e.: the ABI-defined local GOT entries are effectively relocated by
R_MIPS_REL32 (or R_MIPS_REL32+R_MIPS_64 on n64).  The ABI-defined global
GOT entries are effectively relocated by R_MIPS_32 (or R_MIPS_64 on n64).
The new area is for cases where these relocation types are not the ones
we need.

E.g. if TLS support had been defined this way, we could have put TLS
relocs in the new area too, even though some TLS relocs are against
default-visibility globals.  I doubt we'll do that for compatibiility
reasons, but it would still have been a valid use of the new area.

Thanks,
Richard