On 19 March 2012 08:15, Johannes Pfau <nos...@example.com> wrote: > Am Sun, 18 Mar 2012 21:57:57 +0100 > schrieb Jacob Carlborg <d...@me.com>: > >> On 2012-03-18 12:32, Johannes Pfau wrote: >> > I thought about supporting emulated tls a little. The GCC emutls.c >> > implementation currently can't work with the gc, as every TLS >> > variable is allocated individually and therefore we don't have a >> > contiguous memory region for the gc. I think these are the possible >> > solutions: >> >> Why not use the native TLS implementation when available and roll our >> own, like DMD on Mac OS X, when none exists? > > That's what we (mostly) do right now. We have 2 issues: > > * Our own, emulated TLS support is implemented in GCC. This means it's > also used in C, which is great. Also GCC's emulated tls needs > absolutely no special features in the runtime linker, compile time > linker or language frontends. It's very portable and works with all > weird combinations of dynamic libraries, dlopen, etc. > But it has one quirk: It doesn't allocate TLS memory in a contiguous > way, every tls variable is allocated using malloc. This means we > can't pass a range to the GC for the tls variables. So we can't > support this emutls in the GC. >
As far as my thought process goes, the only (implementable in the GDC frontend) way to force contiguous layout of all TLS symbols is to pack them up ourselves into a struct that is accessible via a single global module-level variable. And in the .ctor section, the module adds this range to the GC. This should be enough so it also works for shared libraries too, however I'm sure there is quite a few details I am missing out on here that would block this from working. :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
