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