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:12, Rich Felker <dalias@aerifal.cx> wrote:
> On Thu, Mar 13, 2014 at 10:45:41AM +0000, Will Newton wrote:
>> The current implementation of setcontext uses sigreturn to restore
>> the contents of registers. This contrasts with the way most other
>> architectures implement setcontext:
>>
>>   powerpc, mips, tile:
>>
>>   Call sigreturn if context was created by a call to a signal handler,
>>   otherwise restore in user code.
>>
>>   x86_64, sparc, hppa, sh, ia64, m68k, s390, arm:
>>
>>   Only support restoring "synchronous" contexts, that is contexts
>>   created by getcontext, and restoring in user code.
>>
>>   alpha, aarch64:
>>
>>   Call sigreturn in all cases to do the restore.
>>
>> The text of the setcontext manpage suggests that the requirement to be
>> able to restore a signal handler created context has been dropped from
>> SUSv2:
>>
>>   If  the context was obtained by a call to a signal handler, then old
>>   standard text says that "program execution continues with the program
>>   instruction following the instruction interrupted by the signal".
>>   However, this sentence was removed in SUSv2, and the present verdict
>>   is "the result is unspecified".
>>
>> Implementing setcontext by calling sigreturn unconditionally causes
>> problems when used with sigaltstack as in BZ #16629. On this basis it
>> seems that aarch64 and likely alpha are broken and that new ports should
>> only support restoring contexts created with getcontext and do not need
>> to call sigreturn at all.
>>
>> 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.

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

-- 
Will Newton
Toolchain Working Group, Linaro