[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+T2pCGywjmMoicqo4wPzqu2Ao4QRjxqn3rJCAOAT=u6qRHgzg@mail.gmail.com>
Date: Tue, 13 Feb 2018 23:08:30 -0600
From: William Pitcock <nenolod@...eferenced.org>
To: musl@...ts.openwall.com
Subject: Re: Announce: libucontext 0.1.0 - work in progress
libc-independent ucontext implementation
Hello,
On Tue, Feb 13, 2018 at 10:43 PM, Rich Felker <dalias@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
