This is the mail archive of the
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: Tue, 14 Jan 2014 21:32:58 +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> <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> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DFFC2 at BADAG02 dot ba dot imgtec dot org> <871u185pgu dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6E022B at BADAG02 dot ba dot imgtec dot org> <87wqiy4ewa dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1401101942340 dot 27272 at tp dot orcam dot me dot uk> <87bnzhpn0t dot fsf at talisman dot default>
On Sun, 12 Jan 2014, Richard Sandiford wrote:
> > I'm not sure what to do about sections though -- they are not required in
> > final ELF binaries and not interpreted by ld.so, but we keep them and
> > therefore have to decide how to handle them. We could merge all the
> > original sections into .got, but that could be confusing to some. We
> > could keep original .lit4, .sdata, etc. section names, keeping .got for
> > the legacy GOT part and choosing a new name for the explicitly relocated
> > GOT part. But then the reserved entries wouldn't fit anywhere.
> Yeah, I was wondering this too. Things like .lit4 could be handled even
> in a multigot object, since there's no ODR problem with duplicating the
> contents in each GOT that needs them (i.e. it's not valid to rely on
> address equality for .lit4 entries). So for those I think we could
> end up with the contents being spread across several GOTs. And in
> that case just putting them in .got might be easiest.
> Obviously that isn't possible for .sdata and .sbss: we need to keep
> the original link order. But in principle we could still put .sdata
> in a single secondary GOT.
> It wouldn't be trivial to do any of this and to make it coexist with
> linker scripts though. I'm not sure it's worth spending too much time
> thinking about it unless someone's actually ready to implement it.
Agreed, I'm fine as long as the design is compatible with such an
extension in the future so that we do not need to invent more dynamic tags
or whatever. I do not plan to commence any work in that direction at the
> And I'm not sure whether .sdata and .sbss would be much of a win in
> practice. It would only help with PIEs and DSOs that make relatively
> heavy use of a small amount of global state. How many modern DSOs have
> that pattern?
I haven't made any assessment on that, I'd leave it up to people to
figure out whether they want to use a non-zero -G value for SVR4 code.
I've been asked about the feature a couple times though so it looks like
there's some demand or at least people think they might benefit from it --
whether they're right or wrong about it.
One use might be teaching the compiler to put 64-bit integer immediates
out of line with the new ABIs -- that'd still be .lit8 though I suppose.