musl/arch/sh/pthread_arch.h

static inline struct pthread *__pthread_self()
{
	char *self;
	__asm__ ("stc gbr,%0" : "=r" (self) );
	return (struct pthread *) (self - sizeof(struct pthread));
}

#define TLS_ABOVE_TP
#define GAP_ABOVE_TP 8

#define MC_PC sc_pc

#ifdef __FDPIC__
#define MC_GOT sc_regs[12]
#define CANCEL_GOT (*(uintptr_t *)((char *)__syscall_cp_asm+sizeof(uintptr_t)))
#endif
superh port 2013-10-05 10:13:18 +00:00			`static inline struct pthread *__pthread_self()`
			`{`
			`char *self;`
make thread-pointer-loading asm non-volatile this will allow the compiler to cache and reuse the result, meaning we no longer have to take care not to load it more than once for the sake of archs where the load may be expensive. depends on commit 1c84c99913bf1cd47b866ed31e665848a0da84a2 for correctness, since otherwise the compiler could hoist loads during stage 3 of dynamic linking before the initial thread-pointer setup. 2018-10-16 18:08:01 +00:00			`__asm__ ("stc gbr,%0" : "=r" (self) );`
fix TLS layout of TLS variant I when there is a gap above TP In TLS variant I the TLS is above TP (or above a fixed offset from TP) but on some targets there is a reserved gap above TP before TLS starts. This matters for the local-exec tls access model when the offsets of TLS variables from the TP are hard coded by the linker into the executable, so the libc must compute these offsets the same way as the linker. The tls offset of the main module has to be alignup(GAP_ABOVE_TP, main_tls_align). If there is no TLS in the main module then the gap can be ignored since musl does not use it and the tls access models of shared libraries are not affected. The previous setup only worked if (tls_align & -GAP_ABOVE_TP) == 0 (i.e. TLS did not require large alignment) because the gap was treated as a fixed offset from TP. Now the TP points at the end of the pthread struct (which is aligned) and there is a gap above it (which may also need alignment). The fix required changing TP_ADJ and __pthread_self on affected targets (aarch64, arm and sh) and in the tlsdesc asm the offset to access the dtv changed too. 2018-06-01 23:52:01 +00:00			`return (struct pthread *) (self - sizeof(struct pthread));`
superh port 2013-10-05 10:13:18 +00:00			`}`

			`#define TLS_ABOVE_TP`
fix TLS layout of TLS variant I when there is a gap above TP In TLS variant I the TLS is above TP (or above a fixed offset from TP) but on some targets there is a reserved gap above TP before TLS starts. This matters for the local-exec tls access model when the offsets of TLS variables from the TP are hard coded by the linker into the executable, so the libc must compute these offsets the same way as the linker. The tls offset of the main module has to be alignup(GAP_ABOVE_TP, main_tls_align). If there is no TLS in the main module then the gap can be ignored since musl does not use it and the tls access models of shared libraries are not affected. The previous setup only worked if (tls_align & -GAP_ABOVE_TP) == 0 (i.e. TLS did not require large alignment) because the gap was treated as a fixed offset from TP. Now the TP points at the end of the pthread struct (which is aligned) and there is a gap above it (which may also need alignment). The fix required changing TP_ADJ and __pthread_self on affected targets (aarch64, arm and sh) and in the tlsdesc asm the offset to access the dtv changed too. 2018-06-01 23:52:01 +00:00			`#define GAP_ABOVE_TP 8`
superh port 2013-10-05 10:13:18 +00:00
properly access mcontext_t program counter in cancellation handler using the actual mcontext_t definition rather than an overlaid pointer array both improves correctness/readability and eliminates some ugly hacks for archs with 64-bit registers bit 32-bit program counter. also fix UB due to comparison of pointers not in a common array object. 2015-11-02 17:39:28 +00:00			`#define MC_PC sc_pc`
fix async thread cancellation on sh-fdpic if __cp_cancel was reached via __syscall_cp, r12 will necessarily still contain a GOT pointer (for libc.so or for the static-linked main program) valid for entering __cancel. however, in the case of async cancellation, r12 may contain any scratch value; it's not necessarily even a valid GOT pointer for the code that was interrupted. unlike in commit 0ec49dab6794166d67fae4764ce7fdea42ea6103 where the corresponding issue was fixed for powerpc64, there is fundamentally no way for fdpic code to recompute its GOT pointer. so a new mechanism is introduced for cancel_handler to write a GOT register value into the interrupted context on archs where it is needed. 2018-08-29 18:01:46 +00:00
			`#ifdef __FDPIC__`
			`#define MC_GOT sc_regs[12]`
			`#define CANCEL_GOT ((uintptr_t )((char *)__syscall_cp_asm+sizeof(uintptr_t)))`
			`#endif`