RE: [RFC][PATCH] MIPS ifunc for glibc

["Joseph S. Myers" <joseph@codesourcery.com>]

On Tue, 20 Aug 2013, Jack Carter wrote:

> Is this enough? If not, could you point me to an example I could model after?

What you have doesn't really look like an ABI document at all; it looks 
like an implementation sketch.  I don't know what you mean by "a.outs" at 
all, let alone "Non-shared a.outs" and "Shared a.outs".  Please use the 
appropriate terminology from the gABI and existing psABI documents.  For 
example, if you mean ET_EXEC (which of course excludes PIEs, which are 
ET_DYN objects that can also be executed directory), then say so.  If you 
mean a particular subset of ET_EXEC objects, be clear about what subset 
(again, in standard terms).  If you mean some ET_EXEC and some ET_DYN 
objects, again, make that clear.

The specification should ideally be sufficient for someone to write an 
interoperable static or dynamic linker without needing to refer to an 
existing implementation.

As an example, you could always look at the existing MIPS o32 ABI document 
(from SCO, last updated 1996).  Like many such documents, it is of limited 
current value for reliably describing any ABI in current use.  But it 
indicates the sort of level of detail in such specifications, and thinking 
in terms of what text should be inserted where in the document is a good 
starting point for thinking about how to specify an ABI extension.  Or see 
the non-PIC ABI specification 
<http://gcc.gnu.org/ml/gcc/2008-07/txt00000.txt>.

Among other things, the specification needs to state the values of any new 
relocations....  (Your text mentions both R_MIPS_IRELOCATE and 
R_MIPS_IRELATIVE but never gives them numeric values.)

> > Why aren't you consistently passing the HWCAP value to resolver functions
> > (it seems some places pass it but others don't)?  If you don't pass it
> > from the start, it could be problematic to change the ABI later to start
> > passing it, as applications' IFUNC resolvers wouldn't know if they are
> > being run with a glibc version that passes the HWCAP value to them or not.
> > The ABI document should presumably specify what arguments get passed to
> > the resolver function....
> 
> I am not sure what you mean by passing the HWCAP value to the resolver. 
> The resolver contains logic that determines the HWCAP and from that 
> picks the actual function that is most appropriate for the hardware 
> being run on, returning the address to said function.

In elf_ifunc_invoke, you do

> +  return ((ElfW(Addr) (*) (unsigned long int)) (addr)) (GLRO(dl_hwcap));

but in other places you do e.g.

> +	value = ((ElfW(Addr) (*) (void)) value) ();

and there is no apparent reason for the difference, or any comments 
explaining why it's OK not to pass the argument in some cases - how you 
can know that the resolver functions don't need the argument when called 
in those cases.

> Does the rough ABI I gave above answer your question?

No.  It doesn't seem to say anything about what the type of the resolver 
function is and the significance of its arguments / return value.  
(Regarding the return value, I guess it should also be explicit how 
addresses of MIPS16 / microMIPS functions are returned.)

-- 
Joseph S. Myers
joseph@codesourcery.com