This week's experiment build gdc with tls disabled.

[Iain Buclaw]

On 20 December 2013 07:40, Jacob Carlborg <doob at me.com> wrote:
> On 2013-12-19 20:51, Johannes Pfau wrote:
>
>> Sounds like that could work. But as the module section is a custom
>> section anyway we wouldn't have to replace/modify the default linker
>> script - we can pass a custom script to ld which just handles the
>> ".minfo" section. That should be just as portable as relying on the
>> "don't reorder sections" behavior: Works everywhere where GNU Binutils
>> LD/GOLD are used. (Emitting 3 sections is a clever trick, but it feels
>> like a hack imho. I'm also not sure if we can control the order in
>> which sections are emitted in GCC)
>
>
> The trick with brackting sections doesn't work on Mac OS X. DMD had some
> problems with that. It basically broke on every new major release of Mac OS
> X, the linker changed all the time. If I recall correctly it either removed
> the empty sections or reordered the sections.
>
>

If using GDC on OSX, then you be going through the emutls module I've
got set-up.

As for module discovery, we already generate this in the GDC backend,
which makes it then the job of runtime to pick-up, sort and run the
ctors on all modules:

@attribute("constructor")
void __modinit()
{
  extern (C) __gshared ModuleReference* _Dmodule_ref;
  static private ModuleReference __mymod = ModuleReference(null, minfo);

  __mymod.next = _Dmodule_ref;
  _Dmodule_ref = &__mymod;
}



Unless I'm missing something in how module discovery is supposed to
work, this could be instead amended to:

@attribute("constructor")
void __modinit()
{
  extern (C) void __register_module(ModuleInfo *);

  __register_module(&minfo);
}

So that any lazily loaded modules would be recorded to an existing
list and trigger a run-once ctor run.

Regards
Iain