This week's experiment build gdc with tls disabled.

[Jacob Carlborg]

On 2013-12-18 18:36, Iain Buclaw wrote:

> I'm not so sure about 'module discovery' either.  At least, in
> emulated TLS, it has a completely different concept - each thread has
> a dynamically allocated range (effectively, a void**[] on the heap
> that gets destroyed upon thread termination) which is shared amongst
> all modules / loaded libraries in D for the duration of the thread.
> So when it comes to calling getTLSRange() - what is effectively
> happening is:
>
>    void**[] tlsarray = gthread_getspecific(emutls_key);
>    return cast(void[]) tlsarray[0 .. $];
>
> What I'm hoping is that whatever Martin has done, it is compatible
> with this way of doing things...

After the changes Margin has done DMD now emits .ctors and .dtors 
sections to to every executable and shared library. These will call 
"_d_dso_registry", passing in, among other things, the start and end of 
the module infos.

To get the TLS data the runtime iterates the sections of the 
executable/shared library and collections these.

I don't know if that will be compatible with how it's done in GDC.

This is only for Linux, FreeBSD and Mac OS X behaves as it did before. 
FreeBSD uses bracked sections and Mac OS X doing something similar as 
Linux does now, the dynamic linker has API's for this.

-- 
/Jacob Carlborg