musl/arch/x86_64/pthread_arch.h

static inline struct pthread *__pthread_self()
{
	struct pthread *self;
	__asm__ ("movq %%fs:0,%0" : "=r" (self) );
	return self;
}

#define PC_AT_SYS(c) \
	(*(uint16_t *)(((ucontext_t *)(c))->uc_mcontext.__gregs[16])==0x050f)
Port musl to x86-64. One giant commit! 2011-02-15 12:32:09 +00:00			`static inline struct pthread *__pthread_self()`
			`{`
			`struct pthread *self;`
			`__asm__ ("movq %%fs:0,%0" : "=r" (self) );`
			`return self;`
			`}`
overhaul cancellation to fix resource leaks and dangerous behavior with signals this commit addresses two issues: 1. a race condition, whereby a cancellation request occurring after a syscall returned from kernelspace but before the subsequent CANCELPT_END would cause cancellable resource-allocating syscalls (like open) to leak resources. 2. signal handlers invoked while the thread was blocked at a cancellation point behaved as if asynchronous cancellation mode wer in effect, resulting in potentially dangerous state corruption if a cancellation request occurs. the glibc/nptl implementation of threads shares both of these issues. with this commit, both are fixed. however, cancellation points encountered in a signal handler will not be acted upon if the signal was received while the thread was already at a cancellation point. they will of course be acted upon after the signal handler returns, so in real-world usage where signal handlers quickly return, it should not be a problem. it's possible to solve this problem too by having sigaction() wrap all signal handlers with a function that uses a pthread_cleanup handler to catch cancellation, patch up the saved context, and return into the cancellable function that will catch and act upon the cancellation. however that would be a lot of complexity for minimal if any benefit... 2011-03-24 18:18:00 +00:00
			`#define PC_AT_SYS(c) \`
			`((uint16_t )(((ucontext_t *)(c))->uc_mcontext.__gregs[16])==0x050f)`