This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Mips}Using DT tags for handling local ifuncs
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Jack Carter <Jack dot Carter at imgtec dot com>
- Cc: "Maciej W. Rozycki" <macro at codesourcery dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Thu, 12 Dec 2013 19:44:35 +0000
- Subject: Re: [Mips}Using DT tags for handling local ifuncs
- Authentication-results: sourceware.org; auth=none
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DDC0F at BADAG02 dot ba dot imgtec dot org> <87r49p9dit dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1312092333190 dot 19368 at tp dot orcam dot me dot uk> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DDFC3 at BADAG02 dot ba dot imgtec dot org> <87ob4p6qdt dot fsf at talisman dot default> <87k3fd6owc dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE23E at BADAG02 dot ba dot imgtec dot org> <87txef6a07 dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE3B8 at BADAG02 dot ba dot imgtec dot org> <87haaf5hbg dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE50C at BADAG02 dot ba dot imgtec dot org> <877gbb5c2k dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE59A at BADAG02 dot ba dot imgtec dot org> <8738ly5svc dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE893 at BADAG02 dot ba dot imgtec dot org>
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