Thank you, Daniel, for the explanation of why Debian's glibc is built
the way it is. I knew there would be good reasons.
I am glad to know that 2.6 kernels will work with floating stacks and
the current libc. I have updated the Jikes RVM user's guide to
reflect this. I hope I have accurately
Thank you, Daniel, for the explanation of why Debian's glibc is built
the way it is. I knew there would be good reasons.
I am glad to know that 2.6 kernels will work with floating stacks and
the current libc. I have updated the Jikes RVM user's guide to
reflect this. I hope I have accurately
On Wed, May 05, 2004 at 01:39:33PM -0400, Steven Augart wrote:
> 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 s
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
On Wed, May 05, 2004 at 01:39:33PM -0400, Steven Augart wrote:
> 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 s
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
6 matches
Mail list logo
