cvs commit: src/sys/i386/include tls.h src/gnu/usr.bin/cc34/cc_prep/config dragonfly-spec.h src/gnu/usr.bin/cc34/cc_prep/config/i386 dragonfly.h src/lib/csu/i386 crt1.c src/lib/libc/gen tls.c src/lib/libc/i386/sys cerror.S src/lib/libc/include libc_private.h ...
davidxu at freebsd.org
Wed May 11 18:00:28 PDT 2005
Matthew Dillon wrote:
dillon 2005/05/11 12:47:09 PDT
DragonFly src repository
lib/libc_r/uthread uthread_create.c uthread_init.c
libexec/rtld-elf Makefile debug.h rtld.1 rtld.c rtld.h
libexec/rtld-elf/i386 reloc.c rtld_machdep.h
Major TLS cleanups.
* The RTLD no longer attempts to set up an initial TLS. The job has been
moved to libc. The RTLD does not use TLS itself. The
allocate_initial_tls() function has been removed.
We still have a problem not discussed yet, maybe too hurry here ?
if we want to put user critical section pointer into the tcb,
and used by rtld to block user signal handler, what rtld should
do now ? we have deadlock problem if current thread held reader
lock, and later it catches a signal and in signal handler it tries
to access a __thread variable which causes additional tls data
block to be allocated which needs writer lock. If rtld does not
setup initial tls, then in rlock or wlock, it has to check if
tls was setup or not, it will be diffcult because it does not know
when libc will setup initial tls. What I am thinking is:
in wlock_acquire() or rlock_acquire, rtld will access critical
pointer in tcb, and use an atomic operation:
struct *tcb = tls_get_tcb();
in wlock_release() or rlock_release():
if (tcb->tcb_critical == 0x80000000)
getpid(); // trigger signal handler.
More information about the Commits