2012-11-09 23:36:55 +01:00
|
|
|
static inline struct pthread *__pthread_self()
|
|
|
|
{
|
2013-12-02 02:45:10 -05:00
|
|
|
#ifdef __clang__
|
|
|
|
char *tp;
|
|
|
|
__asm__ __volatile__ ("mr %0, 2" : "=r"(tp) : : );
|
|
|
|
#else
|
|
|
|
register char *tp __asm__("r2");
|
|
|
|
#endif
|
2012-11-09 23:36:55 +01:00
|
|
|
return (pthread_t)(tp - 0x7000 - sizeof(struct pthread));
|
|
|
|
}
|
|
|
|
|
|
|
|
#define TLS_ABOVE_TP
|
|
|
|
#define TP_ADJ(p) ((char *)(p) + sizeof(struct pthread) + 0x7000)
|
|
|
|
|
|
|
|
// offset of the PC register in mcontext_t, divided by the system wordsize
|
|
|
|
// the kernel calls the ip "nip", it's the first saved value after the 32
|
|
|
|
// GPRs.
|
|
|
|
#define CANCEL_REG_IP 32
|
|
|
|
|
fix stack protector crashes on x32 & powerpc due to misplaced TLS canary
i386, x86_64, x32, and powerpc all use TLS for stack protector canary
values in the default stack protector ABI, but the location only
matched the ABI on i386 and x86_64. on x32, the expected location for
the canary contained the tid, thus producing spurious mismatches
(resulting in process termination) upon fork. on powerpc, the expected
location contained the stdio_locks list head, so returning from a
function after calling flockfile produced spurious mismatches. in both
cases, the random canary was not present, and a predictable value was
used instead, making the stack protector hardening much less effective
than it should be.
in the current fix, the thread structure has been expanded to have
canary fields at all three possible locations, and archs that use a
non-default location must define a macro in pthread_arch.h to choose
which location is used. for most archs (which lack TLS canary ABI) the
choice does not matter.
2015-05-06 18:37:19 -04:00
|
|
|
#define CANARY canary_at_end
|