Re: [PATCH 2/4] aarch64: Re-implement setcontext without sigreturn syscall

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Mar 19, 2014 at 05:19:23PM +0000, Will Newton wrote:
> >> This patch re-implements the aarch64 setcontext function to restore
> >> the context in user code in a similar manner to x86_64 and other ports.
> >
> > I question the whole concept of this patch. On aarch64, the kernel
> > stores cpu-model-specific register state that libc won't necessarily
> > know how to restore as part of the context. Of course this isn't
> > needed for synchronous context switches, and it seems you're ok with
> > dropping support for asynchronous ones (from signal handlers), but my
> > impression was that using these interfaces from signal handlers was
> > one of the only reasons they're interesting. Otherwise they're just a
> > glorified setjmp/longjmp, and there's no reason to save/restore ANY
> > registers in the mcontext_t except the call-saved ones (same as
> > setjmp/longjmp do).
> 
> Looking at the list of architectures that do not support asynchronous
> contexts suggests that basically nobody is using that on Linux. I
> would be interested if anyone was aware of software using that
> feature, either on Linux on powerpc/mips/tile, BSD or Solaris.

Well I think "basically nobody" is using any archs but x86[_64] and
arm, at least for some sense of "basically nobody"... ;-) But you may
very well be right. I just sort of question what's the point in even
offering these interfaces on new archs, though, if they don't do
anything significant that setjmp/longjmp can't do.

> > BTW sigreturn is also nice from the standpoint that restoring the
> > signal mask is atomic with respect to switching stacks. Otherwise, if
> > you restore the signal mask before switching, you risk a
> > newly-unmasked signal handler running on the old stack, and if you
> > restore the signal mask after switching, you risk a
> > previously-unmasked signal that should be masked running on the new
> > stack. The only way to solve this problem without sigreturn is to
> > block ALL signals that should be blocked in either the old or the new
> > mask before switching stacks.
> >
> > As for this last issue, I suspect glibc is buggy on other archs with
> > regard to this property...
> 
> But on the other hand sigreturn interacts badly with sigaltstack which
> actually causes problems with real running code (in this case the Go
> language).

Could you explain the bad interaction? I'd be interested in knowing
what it is (since I was planning on using sigreturn to implement the
ucontext functions in musl) and if I knew, I might even have a
workaround.

Rich