public inbox for
 help / color / mirror / Atom feed
From: "Joseph S. Myers" <>
To: Doug Gilmore <>
Cc: <>
Subject: Re: [Patch, mips]: Add support for FR=1/o32. Update implemention of setjmp/longjmp
Date: Wed, 04 Dec 2013 14:56:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 

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 

Joseph S. Myers

      reply	other threads:[~2013-12-04 14:56 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
2013-11-30  8:03   ` Joseph S. Myers
2013-12-04  2:45   ` Doug Gilmore
2013-12-04 14:56     ` Joseph S. Myers [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

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