Ulrich Drepper wrote:
>
> Everything which is not part of glibc is third-party. It's the same as
> if some program would require access to internal data structures of
> libGL. There are several different layouts of the thread descriptor and
> it's only getting worse. The actual layout doesn't matter since
> everything is internal to glibc and the other libraries which come with
> it so this is no problem.
I don't understand the reference to the multiple layouts of the thread
descriptor structure. Can you exlain this?
> Beside, I don't understand why you react like this. Using __thread is
> the best you can ever get. It'll be portable (Solaris 9 already has the
> support as well) and it's faster than anything you can get to access the
> data.
I disagree that __thread is the best you can ever get. In the best
case, you have an extra load and subtraction before you have the address
of a thread-local variable. In the worst case, you have a function call
in there as well.
That is:
movl %gs:0,%eax
subl $foo@tpoff,%eax
movl (%eax),%eax
jmp *1234(%eax)
versus:
movl %gs:32,%eax
jmp *1234(%eax)
for instance. When the function you are jumping to consists of five or
six instructions, say, an extra two instructions are significant.
Recall that a competing operating system on x86 allows access to the
context and dispatch pointers with two instructions, so what you are
suggesting will mean we always have an inferior implementation.
You also need -fpic, which burns a whole register. This is a
non-trivial sacrifice, particularly on x86.
Let's be clear about what I'm proposing: you agree to reserve an
8*sizeof(void *) block at a well-defined and well-known offset in the
TCB. OpenGL is free to access that block, but only that block.
-- Gareth
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
