This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/4] aarch64: Re-implement setcontext without sigreturn syscall
- From: Will Newton <will dot newton at linaro dot org>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 20 Mar 2014 08:23:58 +0000
- Subject: Re: [PATCH 2/4] aarch64: Re-implement setcontext without sigreturn syscall
- Authentication-results: sourceware.org; auth=none
- References: <1394707543-9690-1-git-send-email-will dot newton at linaro dot org> <1394707543-9690-2-git-send-email-will dot newton at linaro dot org> <20140319171245 dot GU26358 at brightrain dot aerifal dot cx> <CANu=Dmix9Wdt2DFuPrDR-KiSXV+mv9gw3-6qupcXGRi9FKFbXQ at mail dot gmail dot com> <20140319173741 dot GV26358 at brightrain dot aerifal dot cx>
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