don't bother with setting up a guard page. Otherwise, round up the size
to page size. Point stack inside the guarded area, without the guard
page. Fix size when mprotect failed.
one. The implementation doesn't provide an async-safe sem_post and can't
without a lot of work on the pthread primitives.
Remove bogus time out requirement in test case, it should have been
a "known failure" if anything.
Require __HAVE_TLS_VARIANT_I or __HAVE_TLS_VARIANT_II as well as
__lwp_getprivate_fast / __lwp_gettcb_fast to exist for libpthread.
Define VAX as going to use TLS variant I, if it is ever implemented.
- Update TCB for the initial thread in pthread__initthread, not
pthread__init to get it valid as soon as possible.
- Don't overwrite the pt_tls field in pthread__initthread.
- Don't deallocate pt_tls in pthread__scrubthread. This worked more by
chance than by design.
- Handle freeing the TLS area in pthread_create after removing the
thread instance from the dead queue.
initialisation order is correct in this case as _lwp_setprivate has been
called already by ld.elf_so for dynamic programs or _libc_init for
statically linked ones.
_rtld_tls_allocate and _rtld_tls_free. libpthread uses this functions to
setup the thread private area of all new threads. ld.elf_so is
responsible for setting up the private area for the initial thread.
Similar functions are called from _libc_init for static binaries, using
dl_iterate_phdr to access the ELF Program Header.
Add test cases to exercise the different TLS storage models. Test cases
are compiled and installed on all platforms, but are skipped on
platforms not marked for TLS support.
This material is based upon work partially supported by
The NetBSD Foundation under a contract with Joerg Sonnenberger.
It is inspired by the TLS support in FreeBSD by Doug Rabson and the
clean ups of the DragonFly port of the original FreeBSD modifications.
libgcc_s's __register_frame_info gets called from libc's CSU code before
the libc constructors are run. __register_frame_info in turn calls
pthread_mutex_lock. libpthread is not initialised at this point and
therefore pthread__self() traps when deferencing the thread register.
This worked before because the garbage from pthread__self() is
effectively ignored.
on all platforms except VAX and IA64. Add fast access via register for
AMD64, i386 and SH3 ports. Use this fast access in libpthread to replace
the stack based pthread_self(). Implement skeleton support for Alpha,
HPPA, PowerPC, SPARC and SPARC64, but leave it disabled.
Ports that support this feature provide __HAVE____LWP_GETPRIVATE_FAST in
machine/types.h and a corresponding __lwp_getprivate_fast in
machine/mcontext.h.
This material is based upon work partially supported by
The NetBSD Foundation under a contract with Joerg Sonnenberger.
the compiler loses information about the size of the object. So instead of
the hacky #define mess we did before, add a way to inject our function between
the user call and the system call.
objects, and the RTLD_NODELETE and RTLD_NOLOAD flags to dlopen(3).
Mark libpthread as DF_1_NOOPEN and use it to test the functionality.
Somewhat taken from FreeBSD.
Fixes PR 42029.
OK from christos and joerg.
the situation, I decided to commit it. There is an inherent problem
with ASLR and the way the pthread library is using the thread stack.
Our pthread library chooses that stack for each thread strategically
so that it can locate the location of the pthread struct for each
thread by masking the stack pointer and looking just below the red
zone it creates. Unfortunately with ASLR you get many random values
for the initial stack, and there are situations where the masked
stack base ends up below the base of the stack. (this happens on
x86 when the stack base happens to be 0x???02000 for example and
your mask is stackmask is 0xffe00000). To fix this, we detect the
pathological cases (this happens only in the main thread), allocate
more stack, and mprotect it appropriately. Then we stash the main
base and the main struct, so that when we look for the pthread
struct in pthread__id, we can special case the main thread.
Another way to work around the problem is unlimiting stacksize,
but the proper way is to use TLS to find the thread structure and
not to play games with the thread stacks.
joerg