musl/arch/arm/pthread_arch.h

typedef char *(*__ptr_func_t)(void) __attribute__((const));

#define __pthread_self() \
	((pthread_t)(((__ptr_func_t)0xffff0fe0)()+8-sizeof(struct pthread)))

#define TLS_ABOVE_TP
#define TP_ADJ(p) ((char *)(p) + sizeof(struct pthread) - 8)

#define CANCEL_REG_IP 18
add support for TLS variant I, presently needed for arm and mips despite documentation that makes it sound a lot different, the only ABI-constraint difference between TLS variants II and I seems to be that variant II stores the initial TLS segment immediately below the thread pointer (i.e. the thread pointer points to the end of it) and variant I stores the initial TLS segment above the thread pointer, requiring the thread descriptor to be stored below. the actual value stored in the thread pointer register also tends to have per-arch random offsets applied to it for silly micro-optimization purposes. with these changes applied, TLS should be basically working on all supported archs except microblaze. I'm still working on getting the necessary information and a working toolchain that can build TLS binaries for microblaze, but in theory, static-linked programs with TLS and dynamic-linked programs where only the main executable uses TLS should already work on microblaze. alignment constraints have not yet been heavily tested, so it's possible that this code does not always align TLS segments correctly on archs that need TLS variant I. 2012-10-15 18:51:53 -04:00			`typedef char (__ptr_func_t)(void) __attribute__((const));`
use __attribute__((const)) on arm __pthread_self function 2012-02-25 02:52:18 -05:00
add support for TLS variant I, presently needed for arm and mips despite documentation that makes it sound a lot different, the only ABI-constraint difference between TLS variants II and I seems to be that variant II stores the initial TLS segment immediately below the thread pointer (i.e. the thread pointer points to the end of it) and variant I stores the initial TLS segment above the thread pointer, requiring the thread descriptor to be stored below. the actual value stored in the thread pointer register also tends to have per-arch random offsets applied to it for silly micro-optimization purposes. with these changes applied, TLS should be basically working on all supported archs except microblaze. I'm still working on getting the necessary information and a working toolchain that can build TLS binaries for microblaze, but in theory, static-linked programs with TLS and dynamic-linked programs where only the main executable uses TLS should already work on microblaze. alignment constraints have not yet been heavily tested, so it's possible that this code does not always align TLS segments correctly on archs that need TLS variant I. 2012-10-15 18:51:53 -04:00			`#define __pthread_self() \`
			`((pthread_t)(((__ptr_func_t)0xffff0fe0)()+8-sizeof(struct pthread)))`

			`#define TLS_ABOVE_TP`
			`#define TP_ADJ(p) ((char *)(p) + sizeof(struct pthread) - 8)`
initial commit of the arm port this port assumes eabi calling conventions, eabi linux syscall convention, and presence of the kernel helpers at 0xffff0f?0 needed for threads support. otherwise it makes very few assumptions, and the code should work even on armv4 without thumb support, as well as on systems with thumb interworking. the bits headers declare this a little endian system, but as far as i can tell the code should work equally well on big endian. some small details are probably broken; so far, testing has been limited to qemu/aboriginal linux. 2011-09-18 16:44:54 -04:00
			`#define CANCEL_REG_IP 18`