three problems are addressed: - use of pc arithmetic, which was difficult if not impossible to make correct in thumb mode on all models, so that relative rather than absolute pointers to the backends could be used. this was designed back when there was no coherent model for the early stages of the dynamic linker before relocations, and is no longer necessary. - assumption that data (the relative pointers to the backends) can be accessed at a constant displacement from the code. this will not be possible on future fdpic subarchs (for cortex-m), so move responsibility for loading the backend code address to the caller. - hard-coded arm opcodes using the .word directive. instead, use the .arch directive to work around the assembler's refusal to assemble instructions not available (or in some cases, available but just considered deprecated) in the target isa level. the obscure v6t2 arch is used for v6 code so as to (1) allow generation of thumb2 output if -mthumb is active, and (2) avoid warnings/errors for mcr barriers that clang would produce if we just set arch to v7-a. in addition, the __aeabi_read_tp function is moved out of the inner workings and implemented as an asm wrapper around a C function, so that asm code does not need to read global data. the asm wrapper serves to satisfy the ABI calling convention requirements for this function.
based on patch by Timo Teräs: While generally this is a bad API, it is the only existing API to affect c++ (std::thread) and c11 (thrd_create) thread stack size. This patch allows applications only to increate stack and guard page sizes.
commit 33ce920857405d4f4b342c85b74588a15e2702e5 broke pthread_create in the case where a null attribute pointer is passed; rather than using the default sizes, sizes of 0 (plus the remainder of one page after TLS/TCB use) were used.
previously, the pthread_attr_t object was always initialized all-zero, and stack/guard size were represented as differences versus their defaults. this required lots of confusing offset arithmetic everywhere they were used. instead, have pthread_attr_init fill in the default values, and work with absolute sizes everywhere.
the thread name is displayed by gdb's "info threads".
Linux's documentation (robust-futex-ABI.txt) claims that, when a process dies with a futex on the robust list, bit 30 (0x40000000) is set to indicate the status. however, what actually happens is that bits 0-30 are replaced with the value 0x40000000, i.e. bits 0-29 (containing the old owner tid) are cleared at the same time bit 30 is set. our userspace-side code for robust mutexes was written based on that documentation, assuming that kernel would never produce a futex value of 0x40000000, since the low (owner) bits would always be non-zero. commit d338b506e39b1e2c68366b12be90704c635602ce introduced this assumption explicitly while fixing another bug in how non-recoverable status for robust mutexes was tracked. presumably the tests conducted at that time only checked non-process-shared robust mutexes, which are handled in pthread_exit (which implemented the documented kernel protocol, not the actual one) rather than by the kernel. change pthread_exit robust list processing to match the kernel behavior, clearing bits 0-29 while setting bit 30, and use the value 0x7fffffff instead of 0x40000000 to encode non-recoverable status. the choice of value here is arbitrary; any value with at least one of bits 0-29 set should work just as well,
per the powerpc psabi, offset 4 of the stack at call time belongs to the callee and is used for spilling lr (return address). in addition, offset 0 on the stack must contain a pointer to the previous stack frame, or a null pointer for the initial stack frame of a thread. __clone failed to setup any stack frame on the new thread's stack, thereby allowing the start function it called to clobber offset 4 of the new thread's struct __pthread, which contains the dtv pointer. add code to setup a proper stack frame and align the stack pointer to a multiple of 16 (also an abi requirement) if it was not already aligned.