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: Wed, 18 Dec 2013 22:26:08 +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> <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> <alpine dot DEB dot 1 dot 10 dot 1312112311480 dot 19368 at tp dot orcam dot me dot uk> <87y53q4czx dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1312121406040 dot 19368 at tp dot orcam dot me dot uk> <87ppp14wr7 dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1312131400280 dot 19368 at tp dot orcam dot me dot uk> <87d2kz4uhi dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DF550 at BADAG02 dot ba dot imgtec dot org> <87ppot6gle dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DF9BE at BADAG02 dot ba dot imgtec dot org>
Jack Carter <Jack.Carter@imgtec.com> writes:
> This is what I think you want:
>
> *) A region in the GOT that only is fixed up by the relocation
> mechanism, not by implicit fixup rules.
Right.
> *) This new region will come after the special GOT entries, but before
> the traditional implicit local entries.
Right.
> *) This new region will have some type of DT pointers and count.
FWIW I was really thinking of just a single new tag to specify the start
of the implicitly-relocated local GOT entries. That's all we need at
the moment and there doesn't seem much point adding anything fancier
since we can never rely on older ld.sos understanding it.
See the glibc change I sketched upthread.
> *) This new region will be visability neutral. It will contain both
> global and local symbols.
Right.
> *) I am assuming that this new region will be sorted to put gp
> relative entries towards the back to reduce multigot triggers.
There's no distinction really. This new region will only be used
for entries that need to be accessed $gp-relative (i.e. it will only
be used for GOT relocations that are present in the input bfds).
FWIW that's also true of the ABI local GOT. Only the global GOT is
special because of the "every symbol involved in a relocation must
have a GOT entry" rule.
ISTR the IRIX linker used the same trick as bfd and put the reloc-only
entries last. I could be misremembering though, since it's many years
since I last had access to IRIX.
> *) I am assuming that this new region will be counted as part of
> DT_MIPS_LOCAL_GOTNO since the special first entries are also a part of
> it.
Right.
> If I this is so, I will start implementation.
>
> This discussion has been very useful to me. I am unlearning what I did
> at sgi and starting to understand how things are done for gcc. Many of
> my assumptions come from my past and don't apply here.
I think you're exaggerating the differences really. Back in 2.16
I got very good test results using binutils on IRIX. That included
multigot support IIRC. There are certainly some genuine differences
between IRIX and GNU/Linux (handled by the various SGI_COMPAT and
IRIX_COMPAT tests you can see sprinkled around). But the basics are
the very much the same.
Of course, GNU/Linux has sprouted various additions that weren't catered
for in the original ABI documents, such as TLS, MIPS16, microMIPS and
the PLT/copy-reloc scheme. And each new feature has to interoperate
with the previous ones. I don't think that's the problem here though;
this whole "new region" thing is working around the ABI GOT as originally
defined in the 32-bit MIPS psABI. The psABI just didn't consider the
possibility that you'd want to apply dynamic relocations to the GOT,
since at the time the only dynamic relocation allowed was R_MIPS_REL32,
and the ABI GOT scheme basically acted like a series of fast R_MIPS_REL32s
(lazy-binding stubs aside).
Sounds like we're on the same page though. :-) Thanks for working through it.
Thanks,
Richard