[PATCHv3, MIPS] Add support for O32 FPXX and program header based ABI information

[Joseph S. Myers]

On Fri, 31 Oct 2014, Matthew Fortune wrote:

> > So you might assume that use of new instructions means a kernel with
> > support for them (and thus a kernel that sets the relevant HWCAP bit), but
> > not a glibc with support for them (so addition of checks in future for
> > HWCAP bits for new ASEs adds safety, but from a starting point where old
> > glibc will run binaries with the new instructions, just without the safety
> > check that the ASE is in fact supported).
> 
> I'm happy to work on that basis if you are OK in principle at least with
> adding safety checks as and when we have HWCAPs defined for protection.

OK in principle (though I believe we'll want a way to disable those checks 
at compile / link time of a binary that uses ASEs with runtime 
conditionals).

> So the plan is:
> 
> * Remove any ASE related checks from this patch
> * Allow ASE checks to be added when there are HWCAPs defined
> * Leave the flags2 check as a way of avoiding bumping the ABIVERSION
>   for future ABI changes. (Not that I'm in any rush to try modifying
>   the MIPS ABIs again!)

* Update the ABI document to state how unknown bits in flags1 and flags2 
should be handled (ignored, and cause the binary to be rejected, 
respectively).

> * If a future ASE needs some special handling which can't be dealt with
>   via flags2 then that would need an ABIVERSION bump.
> 
> Do you think that covers it?

* libc-abis should follow the direction in 
<https://sourceware.org/ml/libc-alpha/2014-10/msg00578.html> (meaning you 
add to the MIPS file, rather than being relative to a tree with a patch 
merging the files applied).

* As <https://sourceware.org/ml/libc-alpha/2014-10/msg00352.html> was 
approved it should be committed so the patch doesn't need to be relative 
to a tree with another uncommitted patch applied either.

-- 
Joseph S. Myers
joseph@codesourcery.com