This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

x86 TLS GNU ABI and user-level thread libraries


Hi

There are some concerns about the GNU ABI for x86 TLS and the
possibility to write user- or two-level thread libraries.

The tls.pdf white paper of 8th february 2003 says for the x86 case:

« For the implementation on GNU systems we can add one more
requirement. The address %gs:0 represents is actually the same as the
thread pointer. I.e., the content of the word addressed via %gs:0 is
the address of the very same location. The advantage is potentially big
since we can access memory directly via the %gs register without loading
the thread pointer rst. »

And indeed it permits for instance to write
        movl    %gs:i@NTPOFF, %eax
instead of
        movl    %gs:0, %eax
	movl    i@NTPOFF(%eax), %eax
in some situations.

But this means that, to perform a user-level context switch, one can't
just modify %gs:0 like with the solaris ABI and similarly to ABIs of
other architectures. One needs to modify %gs too, but since it is a
protected register, it has some cost with either solutions I can see:

- use the set_thread_area() system call to directly modify the address
pointed to by usual content of %gs, but this needs a system call at each
context switch.

- setting up an ldt entry for each new thread and change %gs in
user-level at each switch. But a simple implementation will be limited
to 8192 threads, and since the ldt is shared by all kernel threads of
the same processus, locking is needed. Such centrally locked- system
call for creating user threads on big SMP machines is quite poor.

This small optimisation that the GNU ABI permits on the sole x86
architecture is only interesting when one performs only one local
storage access in some extent. Is it so beneficial compared to the
impossibility to write good user- or two-level thread libraries? I could
read that BSD and L4 people were rather considering using solaris ABI
on this point.

Of course, by giving -mno-tls-direct-seg-refs to gcc one can avoid the
problem, but in some situations you can't recompile programs.

Regards,
Samuel Thibault


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]