Adriaan van Os wrote:
Frank Heckenbach wrote:
Of course, for this also GPC should support thread local variables. ATM GPC does not support thread local variables, mainly because we want to have the same feature set with all backends and older backends (IIRC 3.2 and earlier) do not support them.
Same feature set where reasonably possible. As earlier GCC versions are already obsolescent (I don't want to drop them immediately, but is there any real need for versions before 3.4 anymore?), we should not waste any effort back-porting things. An error message when trying to use them with an earlier backend should be clear enough, so those who need threads will know they have to use 3.3 or newer.
BTW, how are they activated? As a special attribute or something like this? I.e., special handling in the frontend required only at declaration time, or also on usage?
See http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Thread-Local.html.
Thread-local storage (TLS) is a mechanism by which variables are allocated such that there is one instance of the variable per extant thread. The run-time model GCC uses to implement this originates in the IA-64 processor-specific ABI, but has since been migrated to other processors as well. It requires significant support from the linker (ld), dynamic linker (ld.so), and system libraries (libc.so and libpthread.so), so it is not available everywhere.
BTW, if this means it only works with dynamic linking, this would be another reason against. I wouldn't like to give up the option of static linking. (I'm not sure if it means this, or if for static linking the requirements of ld.so simply disappear and .so is replaced with .a.)
Not many targets support it (e.g. Darwin doesn't). So, I don't think we can use the feature (unfortunately).
Not so good. Unless it's foreseeable that a later backend version supports it everywhere, I agree, we shouldn't use it. So we'd have to roll our own, probably similar do how glibc does it for errno.
AFAIUI, the basic idea is to get some thread-unique value (which the thread library probably provides), and use it to retrieve a pointer to the thread-local variable (as an array index, via hashing, list search, etc. -- that's a matter of efficiency which has to be well considered) and automatically dereference the pointer (in C, this is done in a macro).
Frank