This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]