RE: [PATCHv2, MIPS] Add support for O32 FPXX and program header based ABI information

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Joseph Myers <joseph@codesourcery.com> writes:
> On Wed, 14 May 2014, Matthew Fortune wrote:
> > Joseph Myers <joseph@codesourcery.com> writes:
> > > It's normal and OK for code to do things like
> > >
> > >   if (msa_present)
> > >     func_msa ();
> > >   else
> > >     func_non_msa ();
> > >
> > > where the two functions are in different source files, built with
> > > different options.  Or to do the equivalent with IFUNCs.  Or to use the
> > > "target" GCC attribute to have the functions built with different
> options
> > > in the same .o file.  So the presence of MSA instructions in an object
> > > file can't be taken to indicate user intent that the final linked
> > > executable or shared library requires MSA.
> >
> > Absolutely. Such an executable/shared library would not be marked as
> using
> > MSA (because it may not depending on runtime). However an executable that
> > is simply built with MSA enabled throughout will be marked as using the
> > MSA ASE unconditionally. It is the simple case of unconditionally using
> > MSA that I would like to improve error checking for.
> 
> That suggests you need a new -mlink-require-msa or similar option to put
> this setting in an executable / shared library, given that existing
> practice is that use of an option such as -mmsa for some objects does not
> imply an MSA requirement for the result of linking - users don't expect to
> need any special options for code with that sort of runtime checking, they
> just build different objects with different options (and you're unlikely
> to get -mmsa used for all objects in any executable / shared library - if
> nothing else, crt*.o, libgcc etc. probably aren't built with -mmsa - so
> merging on the basis that MSA + non-MSA = non-MSA won't help).

Binutils is tuned for the simple case of users writing code that does not do
runtime checks. i.e. as foo.s -mmsa results in an object that says it uses
the MSA ASE. The merging of ASE usage into an executable or shared library
is an 'OR' so MSA + non-MSA == MSA. To create a shared library or executable
which includes runtime checks before executing any MSA code then the MSA
code has to be hidden:

as foo.s
===
.set push
.set msa
<msa function>
.set pop
===

The resulting object will then 'not' be marked as using the MSA ASE.

This gives us two classes of binary. The ones which include runtime
checks before using MSA are safe by design. The ones which the
average user will build are not 100% safe and can only rely on search
paths being set correctly and MSA-enabled libraries not being found in
a non-MSA search path.

The proposal is just to add a small amount of extra functionality which
serves two purposes:

1) If a program running on non-MSA hardware ends up linking with an
   MSA library then the user is informed via link error instead of
   sigill.
2) If (1) occurs and there are still search paths to look in then the
   dynamic linker may still resolve the dependency with a library that
   can be loaded on the current hardware.

This is a natural extension of the functionality added by FPXX as the
FPXX logic includes this kind of link time rejection in the hope that
a compatible object will be found later.

Thinking about something I wrote last night...
I said I was wrong to have included the HWCAP_MIPS_UFR feature in
HWCAP_IMPORTANT but actually it is probably the right thing to do
as it serves to define a search path (ufr) where FP64 libraries
can be placed.

Regards,
Matthew