This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [Patch, mips]: Add support for FR=1/o32. Update implemention of setjmp/longjmp
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Cc: <libc-ports at sourceware dot org>
- Date: Wed, 4 Dec 2013 14:56:00 +0000
- Subject: Re: [Patch, mips]: Add support for FR=1/o32. Update implemention of setjmp/longjmp
- Authentication-results: sourceware.org; auth=none
- References: <D27A34061895C147B6015779E8B217303D4981CE at KLMAIL01 dot kl dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1311261609530 dot 25885 at digraph dot polyomino dot org dot uk> <529E9700 dot 2090705 at imgtec dot 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