ucontext implementation featuring glibc-compatible ABI
 
 
 
 
Go to file
Ömer Faruk IRMAK f2f46569e7 .pc file should be installed under PKGCONFIGDIR 2020-12-08 12:18:01 +03:00
arch ppc: fix build with libucontext_ namespacing changes 2020-12-06 14:04:22 +00:00
doc add manual page 2020-12-07 18:14:35 -07:00
examples add cooperative threading example 2020-12-07 18:15:18 -07:00
include/libucontext include: add public libucontext/libucontext.h header 2020-12-06 03:53:58 -06:00
.gitignore build: generate libucontext pkg-config file 2020-12-06 04:10:14 -06:00
.mailmap update copyright statements, add mailmap 2020-03-27 09:23:49 +00:00
LICENSE update copyright statements, add mailmap 2020-03-27 09:23:49 +00:00
Makefile .pc file should be installed under PKGCONFIGDIR 2020-12-08 12:18:01 +03:00
NEWS NEWS: not all ports have freestanding yet 2020-12-06 03:45:05 -07:00
README.md README: discuss docs/install_docs and DESTDIR 2020-12-07 18:21:58 -07:00
libucontext.pc.in build: generate libucontext pkg-config file 2020-12-06 04:10:14 -06:00
test_libucontext.c test program: use libucontext-prefixed symbols 2020-12-06 03:32:09 -06:00

README.md

libucontext

libucontext is a library which provides the ucontext.h C API. Unlike other implementations, it faithfully follows the kernel process ABI when doing context swaps.

Notably, when combined with gcompat, it provides a fully compatible implementation of the ucontext functions that are ABI compatible with glibc.

Since version 0.13, for some architectures, you can deploy to bare metal using newlib via the FREESTANDING=yes make option. Systems which use a syscall cannot work this way. The table below shows which architecture ports have been adapted to build with FREESTANDING=yes.

Adding support for new architectures is easy, but you need to know assembly language for the target to do it.

supported features

Architecture Works on musl Syscall Supports FREESTANDING
aarch64
arm
m68k
mips
mips64
ppc
ppc64
riscv64
s390x
x86
x86_64

building

libucontext uses a simple makefile build system. You should define ARCH= at build time, otherwise the build system will attempt to guess using uname -m.

$ make ARCH=x86_64
$ make ARCH=x86_64 check
$ make ARCH=x86_64 DESTDIR=out install

There are a few options:

  • ARCH: The architecture libucontext is being built for. Must be set to one of the architectures listed in the feature support table. If unset, the build system will attempt to guess based on what architecture the host is running. Setting this option explicitly is highly recommended.

  • FREESTANDING: If this is set to yes, the system ucontext.h headers will not be used. Instead, the headers in arch/${ARCH}/freestanding will be used for definitions where appropriate. Default is no.

  • EXPORT_UNPREFIXED: If this is set to yes, the POSIX 2004 names getcontext, setcontext, swapcontext and makecontext will be provided as weak symbols aliased against their libucontext_ namespaced equivalents. This is necessary for libucontext to provide these functions on musl systems, but you may wish to disable this when using FREESTANDING mode to avoid conflicts with the target's libc. Default is yes.

  • DESTDIR: If this variable is set, the installed files will be installed to the specified path instead of the system root.

If you have scdoc installed, you can build manpages and install them:

$ make docs
$ make DESTDIR=out install_docs

caveats

libucontext, while largely functionally equivalent does have some differences over traditional POSIX ucontext functions:

  • Saving and restoring the signal mask is not implemented. This is largely a non-issue because most uses of these functions did not modify the signal mask anyway, but saving/restoring the signal mask (even though it is unmodified in basically all cases in practice) induces a significant performance penalty due to having to make kernel syscalls.

  • Only basic GPR registers are saved and restored when context swapping. The glibc implementation uses hardware capability detection to save/restore other register groups, such as the FPU registers or vector processing (AltiVec/AVX/NEON) registers. Adding this capability detection would significantly increase the complexity of the project and thus is not implemented. Support for compiling in code to save/restore FPU registers or vector registers may be added in a later release as a build-time setting -- for now, we assume a soft-float ABI with no optional processor features. In practice, this does not really matter, code using these functions are unlikely to be impacted by this design assumption.