I appreciate this, especially as Wine may end up using glibc threads
_and_ %fs-based Win32 threads together at the same time.
I was thinking specifically of two attributes:
1. An x86 attribute to say "use this segment prefix when addressing this
object". Where "segment" can be any of the x86 segment registers. That
needn't be considered specific to a thread model.
2. A generic attribute to say references to the object address require
relocation entries adding to a special section.
As a flag on an address, it may be fairly simple to modify the x86
operand output function to add the prefix. You'd also want a warning
when attempting to store the address in a pointer without the attribute,
and you'd want to make sure pointer arithmetic preserves the attribute
etc.
Then __thread_local would be a macro: __attribute__ ((segment ("%gs"),
section (".thread_local"), reloc_section ("__thread_local_reloc")).
The linker script would be extended to place the .thread_local section
in an ELF PHDR with a new flag to indicate thread-specific data.
__thread_local_reloc is just a normal read-only section containing a
table.
Then ld.so would know to duplicate the data on loading, to group all
these PHDR blocks from different libraries together (this can be
incremental), to set up LDT entries to point to all the blocks, and to
relocate all the addresses in __thread_local_reloc (at library load
time) to be offsets from the start of the thread-local blocks.
In the non-threading case (no pthread functions linked in), all the data
would just be accessible in the normal way, without even requiring ld.so
support or a new glibc. No relocations would be needed and the PHDR
flag could be ignored.
And so you'd be able to declare automatic thread-local data in user
programs simply by saying `__thread_local int my_data = 100;' etc.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html