Am Mon, 19 Mar 2012 09:22:01 +0000 schrieb Iain Buclaw <ibuc...@ubuntu.com>:
> On 19 March 2012 08:15, Johannes Pfau <nos...@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.
