[Mips}Using DT tags for handling local ifuncs

[Jack Carter <Jack dot Carter at imgtec dot com>]

Richard,

I started to implement the suggestion of using dynamic tags to process ifunc entries
in the GOT table. The more I worked on it the more it concerns me. Not that it wouldn't
facilitate the GOT fixups to avoid having to go through the iplt stubs, but the danger
introduced for so little real use.

It would only benefit calls from within a pic executable to ifunc routines defined within
the pic executable. It would not benefit non-pic calls, static link calls, calls from dsos
to the pic executable. 

We invision almost exclusive use from ifunc routines defined in dsos. There is not iplt stub
use in that case. And in the case of statically (non-shared) linked executables, I don't 
see any way around iplt stubs.

The MIPS GOT layout assumes that local gots start at DT_PLTGOT and that the global
GOT area starts at the end of the local GOT area. What we have the number of local GOT
entries and number of global GOT entries. A lot of tools work on this assumption. The static
linker is hard coded to work on this assumption

This is not to say that it cannot be done, but is it worth the bang for the buck? How many
debuggers, simulators, object dumpers am I going to mess up making a change that few
will benefit from?

Let me know what you think,

Jack

________________________________________
> From: Richard Sandiford [rdsandiford@googlemail.com]
> Sent: Tuesday, August 20, 2013 1:36 PM
> To: Jack Carter
> Cc: binutils@sourceware.org
> Subject: Re: [RFC][PATCH] MIPS ifunc for binutils
> 
> Jack Carter <Jack.Carter@imgtec.com> writes:
> > I attempted to follow the ARM implementation, but the
> > traditional MIPS GOT design forced me to dirverge a bit.
> > All ifunc functions are represented in .iplt section stubs and
> > in the .igot.plt section table. Each igot.plt entry has an
> > R_MIPS_IRELOCATE relocation record against it with the initial
> > igot entry having link time address of the ifunc routine and
> > after the relocation action, the final runtime target routine
> > address.
> >
> > The only change to the traditional MIPS GOT was to use the .iplt stub
> > address for the defined ifunc function instead of the function address.
> > This should allow seamless multigot support
> 
> Like you said in your earlier message, this seems too big a penalty.
> I think instead we should come up with some way of integrating ifuncs
> into the ABI's GOT scheme.  E.g. we could add a new dynamic tag that sets
> the index of the first local GOT entry, such as DT_MIPS_LOCAL_GOTNO_START.
> When that tag is defined, ld.so would use it instead of the current hard-coded
> 1 or 2 (depending on ELF_MIPS_GNU_GOT1_MASK).
> 
> Then the beginning of the primary GOT could be relocated as normal and we'd
> have control over the relocation order.  (Of course, we'd only want to use
> that area where necessary, since the normal scheme is more efficient for
> the cases that it can handle.)
> 
> That's just one suggestion.  I'm sure there are other ways of doing it.
> But I think we should make whichever change seems best now rather than
> treat it as a future enhancement, otherwise we'll be running the risk
> of compatibility problems.