RE: [Mips}Using DT tags for handling local ifuncs

[Jack Carter <Jack dot Carter at imgtec 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