Re: [Patch, mips]: Add support for FR=1/o32. Update implemention of setjmp/longjmp

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

On Tue, 3 Dec 2013, Doug Gilmore wrote:

> > Also as suggested in that message to the binutils list, I think *context 
> > functions need updating
> An important motivation for adding -mfp64 support is to efficiently
> support the new MSA ISA, which requires the register file to operate
> in -mfp64 mode when MSA instructions are executed.  Since the
> definition of ucontext_t is basically the kernel's struct sigcontext,
> with possibly with some massaging some of the types used in the
> definition, our preference is to wait in adding this functionality
> once MSA context switching support is added to the Linux kernel.

If the functions don't work then it's better for them to be stubs setting 
errno to ENOSYS and with associated stub_warnings, rather than a broken 
function that may return a success status.

Note that the general rule for all such functions - setjmp / longjmp and 
*context - is that you only need to deal with call-preserved registers, 
not call-clobbered ones.  A corollary of this is that it's generally a bad 
idea for new registers in instruction set extensions to be call-preserved 
because that means running code with old libc and using new instruction 
set features can quietly break.  You can choose register preservation 
rules in your ABI supplement (as long as you make GCC match, of course), 
but then any future registers not mentioned in the ABI should be 
call-clobbered.

It is also the case that once a glibc release has been made with a 
particular size for a type such as ucontext_t, any change to that type 
requires symbol versioning unless you can demonstrate there are no issues 
with interoperation of applications built for one type size with 
libraries built for another.

> Is the kernel version check still a concern given that currently there
> is no ToT kernel support for -mfp64?  We just need to add the checks to
> ensure the dynamic linker will only map compatible shared objects.  Right?

There should still be the arch_minimum_kernel setting, to 10.0.0 until the 
support is upstream and then to the actual version where the support goes 
upstream.

-- 
Joseph S. Myers
joseph@codesourcery.com