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: Jack Carter <Jack dot Carter at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail 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: Wed, 11 Dec 2013 22:48:43 +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>
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.
Are the explicit local or not? Are locals just STB_LOCAL or does it include INTERNAL and
HIDDEN as well as PROTECTED?
According to the same document: the local table "consists of local GOT addresses, i.e.
non-preemptible (protected) addresses defined within the executable/DSO."
For whatever it is worth I don't think SGI (me) followed it strictly either. We must have
either pointed the DT_MIPS_GOTSYM at the beginning of the INTERNAL entries (we
ordered them INTERNAL, HIDDEN, PROTECTED, DEFAULT) or subtracted from it to
point into the local got table. If needs be I have an elf dumper that is tuned to SGI MIPS
and can deconstruct the algorithm.
>
> Whichever way you look at it, the implicitly-relocated local GOT stops
> at index DT_MIPS_LOCAL_GOTNO. What I'm proposing wouldn't change that.
> DT_MIPS_LOCAL_GOTNO isn't the number of entries that get R_MIPS_REL* treatment.
>> 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.
Once again, push comes to shove we could have another DT_MIPS_GOTSYM
variant that point to a different point in the .dynsym table.
>
> 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.
>
> If you think the ER region should come after the global GOT too, as in:
>
> local GOT
> global GOT
> ER GOT
No, this is not what I suggest and it would be terrible idea.
>
> Thanks,
> Richard