GS register to access thread-specific state on x86
Dear debian-glibc list,
It appears that libc6 on the x86 Debian (at least libc6-2.3.2-ds1-11)
is not compiled to access thread-specific state via the GS register;
instead, it seems to rely upon masking the low-bits of the stack
pointer, expecting to find the thread-specific state at the base of
the stack. This means it gets very upset if a program manipulates the
stack pointer.
This breaks Jikes RVM, and will break any other program which does its
own m:n threading on top of the native threading system. (There is a
partial workaround for Jikes RVM where one can tell the system to not
use the pthread system at all, but instead to only use its built-in
m:n threading system; that keeps glibc's thread system from ever
getting involved, but has other undesirable consequences.)
Red Hat Linux and SuSE Linux, at least, stopped compiling their
versions of glibc this way back at least two years ago, before either
of them released their 7.3 versions. I would like to understand why
Debian still builds glibc in this way. I'm sure there must be a good
reason for it, which is why I haven't reported this as a bug.
I have been searching the debian-glibc archives and the BTS, but have
not been able to find any discussions of this. Is there any past
discussion of this on the debian-glibc list that someone could point
me to? (I am a new subscriber to this list.)
I'm also asking whether there have been any work-around for this where
packages have managed to manipulate the stack pointer and still take
advantage of the pthreads support in Debian's glibc.
At the moment, the Jikes RVM user's guide recommends that folks run
Red Hat or SuSE. I would very much like to add Debian to the list of
recommended systems.
Thank You.
--Steven Augart
--
Steven Augart
Jikes RVM, a free runtime system for Java
http://oss.software.ibm.com/jikesrvm
Reply to: