From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Matheus Almeida <Matheus.Almeida@imgtec.com>
Cc: "libc-ports@sourceware.org" <libc-ports@sourceware.org>,
Doug Gilmore <Doug.Gilmore@imgtec.com>
Subject: Re: [Patch, mips]: Add support for FR=1/o32. Update implemention of setjmp/longjmp
Date: Tue, 26 Nov 2013 16:25:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1311261609530.25885@digraph.polyomino.org.uk> (raw)
In-Reply-To: <D27A34061895C147B6015779E8B217303D4981CE@KLMAIL01.kl.imgtec.org>
On Tue, 26 Nov 2013, Matheus Almeida wrote:
> This patch updates the definition of setjmp, longjmp and jmp_buf so that
> on a call to setjmp/longjmp, all the required floating-point
> callee-saved registers are properly saved/restored.
>
> We are aware that updating the size of jmp_buf can potentially break
> existing applications but we expect the number of applications built
> with FR=1 mode to be very small, possibly zero. Nevertheless this should
> be clearly stated in the release notes that existing applications built
> with FR=1 (-mfp64) need to be recompiled in order to use new versions of
> the library.
I don't recall a response to
<https://sourceware.org/ml/binutils/2013-09/msg00045.html>, and don't see
one in the binutils list archives. I believe that just like the NaN
changes, this needs to be considered as an incompatible ABI variant, with
ELF header checks in the dynamic linker to ensure that all loaded objects
are compatible (whether or not you also define new dynamic linker names
for one or both of o32/-mfp64/legacy-NaN and o32/-mfp64/NaN-2008) -
incompatibilities should be detected by the dynamic linker, not "need to
be recompiled". I suggest looking at Maciej's NaN changes as a model.
Also as suggested in that message to the binutils list, I think *context
functions need updating as well as setjmp/longjmp, and there should be an
ABI supplement document explaining o32 function call and return for
-mfp64.
What's the kernel.org kernel version with support for this feature (that
is, the kernel that checks the ELF header flag and ensures the FPU is
correctly set up for the process)? As with NaN-2008, arch_minimum_kernel
should be set to the appropriate kernel version, or 10.0.0 until the
relevant support is in the kernel.org tree.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2013-11-26 16:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 11:34 Matheus Almeida
2013-11-26 16:25 ` Joseph S. Myers [this message]
2013-11-30 8:03 ` Joseph S. Myers
2013-12-04 2:45 ` Doug Gilmore
2013-12-04 14:56 ` Joseph S. Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1311261609530.25885@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=Doug.Gilmore@imgtec.com \
--cc=Matheus.Almeida@imgtec.com \
--cc=libc-ports@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).