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

That's fine. I was holding off just in case the discussion on this patch
ended up changing the hook.

Am I alright to request commit access to glibc with you as reference?

Thanks,
Matthew