Supporting emulated tls

[Johannes Pfau]

Am Sun, 18 Mar 2012 21:57:57 +0100
schrieb Jacob Carlborg <doob at 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.

* The other issue with native TLS is that using bracketing with
  __tls_beg and __tls_end has corner cases where it doesn't work. We'd
  need an alternative to locate the TLS memory addresses and TLS sizes.
  But there's no standard or public API to do that.

> BTW, I think it would be possible to emulate TLS in a very similar
> way to how it's implemented natively for ELF.
> 

I don't think it's that easy. For example, how would you assign module
ids? For native TLS this is partially done by the compile time linker
(for the main application and libraries that are always loaded), but if
no native TLS is available, we can't rely on the linker to do that. We
also need some way to get the current module id in running code.

And how do we get the TLS initialization data? If we placed it into an
array, like DMD does on OSX, we could use dlsym for dlopened libraries,
but what about initially loaded libraries?

Say you have application 'app', which depends on 'liba' and 'libb'. All
of these have TLS data. Maybe we could implement something using
dl_iterate_phdr, but that's a nonstandard extension.

Compare that to GCC's emulation, which is probably slow, but 'just
works' everywhere (except for the GC :-( ).