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: Thu, 19 Dec 2013 18:17:13 +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> <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>
Richard,
First of all, I have found you very pleasing to work with and don't find you
to be a dictator or the such.
It is not a "your wrong", but just I see it differently. The abi is like a religious
book. We treat some passages as in stone written rules and others as simply
guidelines.
Through my eyes having a commandline option to reduce the GP area is essential
to testing. It doesn't take away from testing the legal limits which is crucial, but it really pushes
the code with smaller easier to read bits. And yes, using .rept will help me :-)
I also have a hard time with how the GOT is used for binutils. In my experience and world
view, sections have attributes that make them gp relative or not. All these sections get
gathered in gp relative regions that are 64k from a value that will be in their $GP. If there
are GOT elements that are not gp relative, they should be in another .got that is not marked
SHF_MIPS_GPREL. It will not get laid out and calibrated with any of the other GOTs.
Other sections in my life that get bundled up in the equation for multigot are .sbss, .sdata,
.lit[4,8,16], .srdata, but only if they are marked SHF_MIPS_GPREL.
If TLS symbols aren't gp relative they should be in a separate GOT section.
We all have already broken the concept of "the GOT" as a monolithic element with multigot.
Separating the gp rel portion from the non-gprel portion from the get-go should not
blasphemy.
The DT_MIPS_LOCAL_GOTNO describes local got entries. Not other partitions that we
reserve the right to put non-local got entries.
But this is my view of the world having worked on MIPS linkers at one company for a long
time. Also, as time goes by, one remembers things maybe a bit differently than reality ;-)
You are correct, if we applied the implicit R_MIPS_IRELATIVE as opposed to the the stated
it would go against the stated " R_MIPS_REL32 relocation type is the only relocation performed
by the dynamic linker". I want to bend the rules where it suits me too. 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.
The bottom line for me is that mechanism for ifunc we have hashed out and agreed to move
forward on works in the mold of where ld and ld.so are at this point. That doesn't mean
that it fits in my view of the linker world. It doesn't have to. It is just another way of looking
at it.
I'm not at all angry, just want to agree to disagree on some things. If I think that something is
truly going to hurt us forever and ever, I will truly balk. This is not the case now, with possibly
the exception of allowing globals in the local area ;-) I will probably fight that description before
we write up the final abi on this.
Cheers and looking forward to continued collaboration,
Jack
________________________________________
From: Richard Sandiford [rdsandiford@googlemail.com]
Sent: Thursday, December 19, 2013 7:48 AM
To: Jack Carter
Cc: Maciej W. Rozycki; binutils@sourceware.org; Doug Gilmore
Subject: Re: [Mips}Using DT tags for handling local ifuncs
Jack Carter <Jack.Carter@imgtec.com> writes:
> To be honest I don't agree with many of the conclusions below. No, I
> have not added any new comments ;-)
Which bits don't you agree with? I'm not trying to dictate here.
I just honestly don't understand yet what your disagreement is.
I certainly don't want to implement something on the basis of
"you're wrong, but I'll do it anyway".
Thanks,
Richard