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

[Will Newton <will dot newton at linaro dot org>]

On 19 March 2014 17:37, Rich Felker <dalias@aerifal.cx> wrote:
> 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.

Because existing software uses them, for better or worse.

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

https://sourceware.org/bugzilla/show_bug.cgi?id=16629

-- 
Will Newton
Toolchain Working Group, Linaro