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

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

Joseph S. Myers <joseph@codesourcery.com> writes:
> 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.

OK. I am perhaps being over-cautious owing to the underlying floating-point
mode issues and wanting to try my best to protect against future ASEs having
some form of modal requirement.

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

Agreed. I'm taking the same stance when discussing architecture extensions
internally and also on any other tools discussion. I think the S390 problems
have raised awareness of this issue for the whole community.

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

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.

> 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

I was trying to achieve that yes. I guess the ODDSPREG flag should really
have gone in to flags2 given it was not just informational but since it
was introduced with the initial specification of .MIPS.abiflags then it
doesn't really make much difference. If we were to have added such a flag
after the initial version then it would definitely have gone in flags2.
Flags1 is also defined to be a simple bitwise-OR of all input objects where
flags2 is expected to have custom rules for any bits which get defined.

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

I fully intend to make that work. My intention is to specify that as part
of ifunc work. From an assembler level this should be OK already but from
the compiler there is work to do, the FP mode requirements complicate it
as well.

> > +  /* 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.

I can do that. I was concerned about someone updating the list of FP ABIs
but not updating the table in dl-machine-reject-phdr.h and it leading to 
some strange runtime crashes. If I just size the 'reqs' table using
Val_GNU_MIPS_ABI_FP_MAX then any future ABI extension will get a zero
initialised entry which would be ideal.

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!)
* 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?

Thanks,
Matthew