Re: Announce: libucontext 0.1.0 - work in progress libc-independent ucontext implementation

[William Pitcock <nenolod@dereferenced.org>]

Hello,

On Tue, Feb 13, 2018 at 10:43 PM, Rich Felker <dalias@libc.org> wrote:
> On Tue, Feb 13, 2018 at 09:42:36PM -0600, William Pitcock wrote:
>> Hello,
>>
>> I am pleased to announce the 0.1.0 release of libucontext, a library
>> which implements the ucontext.h functions (getcontext, setcontext,
>> makecontext and swapcontext), originally meant for use with gcompat,
>> but also useful for applications requiring the functions outside of
>> gcompat (such as when building against musl directly).
>>
>> Implementation completeness varies based on each architecture, with
>> the goal of having complete implementations across all presently
>> supported architectures in the next release, but, it should be noted
>> that for the most part the implementations provide workable behaviour
>> in real-world apps right now.  In other words, it's what you would
>> expect for a 0.1.0 release.
>>
>> To use these functions, you just link to `-lucontext`, meaning you
>> could provide them in $LIBS when running configure scripts and have
>> everything most likely work out nicely.
>>
>> Download: http://distfiles.dereferenced.org/libucontext/libucontext-0.1.0.tar.xz
>> Building should hopefully be straightforward too.
>>
>> For Alpine and Adelie distributions, this package is available as
>> libucontext in the testing repository.
>
> Looks good. A couple observations:
>
> 1. Your implementations don't seem to save or restore signal masks.
> This of course makes them much faster and "better" for implementing
> coroutines etc., but if applications using them actually expect them
> to keep a context-local signal mask, they'll break.

Signal masks are a planned feature in 0.2.0.  0.1.0 is mainly meant to
be a proof of concept.

> 2. Your asm makes effort to save and restore call-clobbered registers.
> setcontext does need to restore them if you want to be able to return
> to asynchronous contexts (like the ucontext argument to a signal
> handler) correctly, but there's no point in saving the call-clobbered
> registers in getcontext, since these registers are purely the
> getcontext function's "local variables", not a meaningful part of the
> context. Likewise the /* we need to restore %ecx because we clobbered
> it earlier */ comment in x86 getcontext.S does not make sense.

You're right, we don't need to bother with fixing %ecx after saving
the FS segment.

William