Re: Fast thread-local storage for OpenGL drivers

[Jakub Jelinek <jakub redhat com>]

On Sat, Feb 22, 2003 at 10:32:05AM -0800, Gareth Hughes wrote:
> Two or three pointers.  I'm pretty sure we use less than 8 pointers all up,
> although many of those aren't performance critical.  Three of ours most
> definitely are, and it would be nice if moving to a couple more didn't break
> things.  We only ever use thread-local pointers, never whole structs or
> anything like that.

What actually matters is the size of PT_TLS segment of the shared library
which defines those 2-3 __thread variables (I assume it is libGL.so,
right?).
When at least one of STT_TLS symbols from some dlopened library is accessed
using IE or LE model relocs, then this whole PT_TLS segment must
be put into the surplus area.
If possible, keep this at 2-4 pointers, so that other libraries can use
it for their performance critical things too if needed.
It would be good if the rest of __thread variables which aren't performance
critical is provided by some other library (and accessed always through GD or
LD model).

> Will this be okay, considering that two shared libraries will need access to
> the variables (libGL.so itself and the driver backend)?  Can you use IE or
> LE with variables that live in another shared library?

See above, it doesn't matter what all libraries use IE/LE relocs, it matters
what shared library provides those TLS symbols those relocs resolve to.

> Sure, the code itself isn't hard to understand.  The problem is, at runtime,
> how do I know what code to generate to access a given __thread variable?  Do
> I have do disassemble a function that accesses the variable to know the
> right model to use?  Fixed offsets make this trivial, but maybe this isn't a
> real problem after all.

Forgot to say, the offsets are obviously constant (until you dlclose the
library which declares them).
If they weren't, one couldn't keep pointers to __thread variables around
in IE/LE models.

	Jakub