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

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

On Mon, 20 Oct 2014, Matthew Fortune wrote:

> For the flags2 and undefined ASE checks I can actually remove them and
> add them alongside a further ABIVERSION increase in the future. That

For undefined ASEs, I think it's a mistake to test for them in glibc.

The normal assumption is that minimal hardware enablement for new 
processor features may need a new kernel (after all, the kernel needs to 
handle the new registers on context switch, if nothing else) but shouldn't 
need new glibc binaries (this is why new registers should be 
call-clobbered); given a new kernel, you should be able to use the new 
instructions with existing glibc binaries on your new hardware.

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).

As for flags2 - the ABI document seems silent on how to tell whether a new 
flag is compatible with old dynamic linkers (i.e., whether it's safe to 
ignore it).  This is of course a common problem with other interfaces 
(various Linux kernel interfaces quietly ignore unknown flag bits, causing 
problems for programs that then need to check whether the flag they passed 
in was handled properly).  I suppose you could define parts of the flag 
space as being safe to ignore and other parts as not being safe to ignore 
(if necessary, you can always move bits from not-safe-to-ignore to 
safe-to-ignore in future, at the cost of needing a more recent dynamic 
linker to handle binaries setting those bits).  Is the design here that 
flags2 is not-safe-to-ignore but flags1 is safe-to-ignore?  That appears 
to be how this patch is using the bits (even though the one bit defined 
and tested for in flags1 seems to be to fall into not-safe-to-ignore).

(I also still think that if you have MSA HWCAP bits there should at least 
be a compiler / assembler / linker option to build a binary that uses MSA 
but is not marked as doing so, for use when doing dynamic detection of MSA 
availability - this shouldn't only be available through "target" 
attributes to compile individual functions with MSA.)

> +  /* Unknown ABIs are rejected.  */
> +  if (in_abi != -1 && in_abi > Val_GNU_MIPS_ABI_FP_64A)
> +    REJECT ("   uses unknown FP ABI: %u\n", in_abi);

I think it would be better for the header to have a name such as 
Val_GNU_MIPS_ABI_FP_MAX rather than hardcoding the information here that 
Val_GNU_MIPS_ABI_FP_64A is, of the ABIs known to glibc, the one with the 
highest number.

-- 
Joseph S. Myers
joseph@codesourcery.com