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

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Wed, 11 Dec 2013, Jack Carter wrote:

> Unless this last argument below can convince you or at least give you pause
> to consider "implicit, explicit, default" ordering, I will start on "explicit, implicit, 
> default".
> 
> I don't think it is the "right" thing to do, but what the heck, what is right and wrong
> anyway? What you are proposing should be workable. I just need to get it correctly
> written up before shipping.

 Regrettably I still haven't had the time to absorb all the details of 
this stuff, but I think I've ingested enough to ask one question: given 
that explicit dynamic relocs will be used anyway, does this new chunk of 
run-time relocatable data have to be a part of the GOT as defined by the 
traditional SVR4 MIPS psABI in the first place?  How about we leave the 
current definitions of the DT_PLTGOT and DT_MIPS_LOCAL_GOTNO dynamic tags 
and the .got special section intact?

 I gather all that is needed is that ifunc pointers are reachable with 
gp-relative addressing (so that the same standard calling sequence can be 
used, either the SVR4 PIC or the non-PIC PLT type, regardless of whether 
calling an ifunc or an ordinary function), so grouping them in a section 
called .igot.plt and then either prepending or appending to .got should 
do; with a linker script even.  Of course the static linker will have to 
ensure that all the pointers in the combined sections are in range from 
$gp (and the same with secondary $gp values in the multi-GOT case).

 The dynamic linker will then be able to resolve all R_MIPS_IRELOCATE 
relocs right away (by calling the respective ifunc resolvers by hand and 
installing the value returned in the relocated location) if LD_BIND_NOW 
has been set or otherwise they will be merely adjusted by the base address 
so as to point to the ultimate locations of individual ifunc resolver 
stubs otherwise (so that the first time a call to the ifunc is made the 
relevant ifunc resolver will be called instead, via a generic wrapper that 
will install the value returned in the relocated location).

 Under this scheme no new dynamic tag is needed I believe.  All that's 
required for lazy resolution is to have the stubs load the respective 
relocation table's entry index (relative to DT_REL/DT_RELA, that'll be 
added to having multiplied the index by DT_RELSZ/DT_RELASZ) into a 
temporary register so that the wrapper knows which relocation to process.

 Am I missing anything here?

 BTW, for loading 64-bit addresses I suggest using two temporaries (we've 
got plenty of them) for a sequence that is faster on superscalar 
processors, i.e. rather than:

static const bfd_vma mips64_exec_iplt_entry[] =
{
  0x3c0f0000,	/* lui $15, %highest(.got.iplt entry)        */
  0x65ef0000,	/* daddiu $15, $15, %higher(.got.iplt entry) */
  0x000f7c38,	/* dsll $15,$15, 16                          */
  0x65ef0000,	/* daddiu $15, $15, %hi(.got.iplt entry)     */
  0x000f7c38,	/* dsll $15,$15, 16                          */
  0x01f90000,	/* l[wd] $25, %lo(.got.iplt entry)($15)      */
  0x03200008,	/* jr $25                                    */
  0x00000000,	/* nop                                       */
};

use:

static const bfd_vma mips64_exec_iplt_entry[] =
{
  0x3c0f0000,	/* lui $15, %highest(.got.iplt entry)        */
  0x3c0e0000,	/* lui $14, %hi(.got.iplt entry)             */
  0x25ef0000,	/* addiu $15, $15, %higher(.got.iplt entry)  */
  0x000f783c,	/* dsll32 $15, $15, 0x0                      */
  0x01ee782d,	/* daddu $15, $15, $14                       */
  0xddf90000,	/* ld $25, %lo(.got.iplt entry)($15)         */
  0x03200008,	/* jr $25                                    */
  0x00000000,	/* nop                                       */
};

(this also avoids a DADDIU erratum early R4000/R4400 chips had).

  Maciej