This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] mips: Remove rt_sigreturn usage on context function
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 24 Jun 2019 17:55:01 +0100 (BST)
- Subject: Re: [PATCH 2/2] mips: Remove rt_sigreturn usage on context function
- References: <20190215141132.24404-1-adhemerval.zanella@linaro.org> <20190215141132.24404-2-adhemerval.zanella@linaro.org> <54030d10-6aa4-db18-22a4-da5da935ee93@linaro.org> <alpine.LFD.2.21.1906010259420.17693@eddie.linux-mips.org> <9d8a3105-994e-2bdb-fe77-82d224607e16@linaro.org>
On Mon, 3 Jun 2019, Adhemerval Zanella wrote:
> > This is an obsolete interface, but FYI according to the relevant version
> > of SUS[1] you are supposed to be able to return from a signal handler by
> > calling setcontext(3) similarly to siglongjmp(3) and by removing this code
> > you make the context not to be fully restored in that case (on the MIPS
> > target the distinction is due to the DSP register state).
> >
> > What do you mean by: "setcontext is not async-signal-safe"? I think such
> > an assertion (if indeed true) should have been explained in the commit
> > message even if it was previously discussed (where?).
>
> It is in fact blurry on POSIX 2001, since it defines on '3. Definitions' [1] that
> function *is not* async-cancel-safe unless explicitly described as such and
> later on '2.4 Signal Concepts' [2] it defines the function set that should be
> async-signal-safe and it does not list 'setcontext' as one.
Well, it says specifically that:
"[An async-cancel-safe function is] A function that may be invoked,
without restriction, from signal-catching functions."
which in my opinion does not preclude a non-async-cancel-safe function to
be called with some restrictions. And the description of the function
clearly states it is intended to be used in a signal handler. So while we
may not be required by the standard to produce a predictable result, we
certainly are allowed to if feasible.
NB `siglongjmp' isn't listed as an async-cancel-safe function either and
I think we have no doubt as to whether it can be called in a signal
handler and produce a predictable result.
> It is even more complicated because this is not portable over architectures on
> Linux, since:
>
> 1. not every one supports rt_sigaction. It means that either that architecture
> does not really require additional context that userland might not
> save/restore or that architecture extensions save/restore are not really
> supported.
> For instance, it seems that newer architectures (like RiscV) follow this
> approach and just really support synchronous by saving/restore the preserved
> state. It is the same with some newer ABI extension, such as AArch64 SVE.
>
> 2. Not every architecture passes an mcontext_t and third argument for signal
> handlers with SA_SIGINFO (sparc and ia64 for instance).
>
> 3. Even for architecture that does support passing an mcontext_t, userland
> can not have enough information that some context is lazy-saved (such some
> architecture extension such as vector register) by the kernel.
>
> So that's why I think setcontext is not really aync-signal-safe and it is really
> hard to get it right in Linux (check powerpc complexity over time to support
> Altivec and later VSX) and while it is support is very architecture-specific.
Perhaps Power would have to define and use a set of syscalls to aid the
userland in selecting the set of registers to save and restore. It was
proposed for the MIPS/Linux port too, but it turned out unnecessary.
I see no need or sense to remove what used to just work.
> I am not really against reverting the patch, and it might be better outcome for an
> already deprecated symbol, but my idea was to make it somewhat more sane and
> portable on Linux.
In what sense portable?
Maciej