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.