This week's experiment build gdc with tls disabled.

[Johannes Pfau]

Am Wed, 18 Dec 2013 17:36:53 +0000
schrieb Iain Buclaw <ibuclaw at gdcproject.org>:

> On 18 December 2013 15:39, Johannes Pfau <nospam at example.com> wrote:
> > Am Tue, 17 Dec 2013 21:12:41 +0100
> > schrieb "David Nadlinger" <code at klickverbot.at>:
> >
> >> On Tuesday, 17 December 2013 at 20:07:41 UTC, Iain Buclaw wrote:
> >> > The hidden subtext that you didn't understand being, I'm
> >> > holding back on Martin's patches for now.
> >>
> >> That subtext isn't exactly hidden, given the first sentence in
> >> your first post. ;)
> >>
> >> Do you have a plan yet regarding how to implement module
> >> discovery for shared libraries? Would be a good idea to
> >> coordinate efforts and find a solution that works for all the
> >> backends, as Martin has been suggesting as well.
> >>
> >> David
> >
> > I hope I'm not talking bullshit here as I'm not 100% sure what's
> > meant with 'module discovery'.
> >
> 
> 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...

I guess you can add the scan code here:
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/tlsgc.d#L62