Supporting emulated tls

[Johannes Pfau]

Am Mon, 19 Mar 2012 09:22:01 +0000
schrieb Iain Buclaw <ibuclaw at ubuntu.com>:

> On 19 March 2012 08:15, Johannes Pfau <nospam at example.com> wrote:
> >
> > * 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. :)
> 

Good idea, I should have thought about that. I can't think of a
reason why it wouldn't work and it should be quite fast as well.

Just to clarify: 'module-level' as in D module(/object file) or as in
one variable per shared library/application? If we can support one
variable per shared library/application that'd be great, as we will
then only have a few tls ranges for the gc.