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: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Jack Carter <Jack dot Carter at imgtec dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Fri, 10 Jan 2014 18:32:37 +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> <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> <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> <87txe5aw74 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DFD62 at BADAG02 dot ba dot imgtec dot org> <871u18c04i dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DFDA5 at BADAG02 dot ba dot imgtec dot org> <8761qk6045 dot fsf at talisman dot default>
On Thu, 19 Dec 2013, Richard Sandiford wrote:
> > Dealing with the ifunc "local" entries implicitly will save a
> > relocation lookup, a tiny blip of time in relation to the other costs
> > of calling the resolver. So I am arguing about how many angels can
> > dance on a pin.
>
> Yeah, maybe this is one we'll have to agree to disagree on. I think the
> benefit of having an implicitly-relocated irelative region is small at best.
> I like the generality of including the GOT R_MIPS_IRELATIVE GOT
> relocations in the general .rel.dyn pool and sorting them accordingly,
> because it feels more future-proof. I also think an implicit region is
> harder to handle in a backward-compatible way, since if we just add new
> tags, older ld.sos would ignore them and not flag an error.
>
> If someone else has any opinions about implicit irelative relocs vs.
> explicit irelative relocs though, please shout.
I do, I think that while looking smart at first the concept of implicit
GOT relocation on the MIPS target proved inflexible and difficult to
maintain over the years (see e.g. the troubles with the __ehdr_start
special symbol we had recently). By using explicit relocs the
inflexibility is removed and the likelihood of the need to add another
special region in the GOT in the future minimised. I haven't analysed any
program startup performance implications this may have though.
NB as far as ld.so's backwards compatiblity is concerned I think we can
sort it out in either case, e.g. we could poison binaries with a dummy
relocation old ld.so would choke upon. Or there might be another,
prettier way possible too, to be found by examining ld.so and seeing its
abnormal termination conditions.
Maciej