This week's experiment build gdc with tls disabled.

[David Nadlinger]

On Wednesday, 18 December 2013 at 15:39:30 UTC, Johannes Pfau 
wrote:
> I hope I'm not talking bullshit here as I'm not 100% sure 
> what's meant
> with 'module discovery'.
>
> But if the question is how to get all ModuleInfos in a library, 
> […]

Yes, this was the idea.

> We can then access the bracket-symbols from a 
> module-constructor (or a
> c-like .ctor constructor) in the library? So we'd have to add
> drtbegin.o / drtend.o files to every d library or executable.

That is pretty much how it is done in DMD and LDC as well. The 
only difference is that instead of modifying the linker scripts 
to accommodate this, we emit the ModuleInfo references to custom 
sections. The GNU toolchain (and we are in highly system-specific 
territory here anyway) never changes the order of custom 
sections, which you can also verify using 
__attribute__((section("...))) in GCC. Thus, if you emit your 
relevant symbols into three sections like this,

a.o
---
_minfo_beg: moduleInfoBeginTag
_minfo: moduleInfoForA
_minfo_end: moduleInfoEndTag

b.o
---
_minfo_beg: moduleInfoBeginTag
_minfo: moduleInfoForB
_minfo_end: moduleInfoEndTag

the linked result will be

_minfo_beg: moduleInfoBeginTag
_minfo: moduleInfoForA moduleInfoForB
_minfo_end: moduleInfoEndTag

and you can just use [moduleInfoBeginTag, moduleInfoEndTag) to 
get a list of all available ModuleInfos.


Of course, once shared libraries come into play, you have to 
consider quite a few subtleties regarding symbol visibility and 
so on. Also, due to a bug in LLVM, LDC can't emit weak symbols 
with custom section names, so we end up with multiple copies of 
the begin/end symbols and the C .ctor/.dtor table entries.

But in general, this works quite well, and is certainly much more 
portable than requiring changes to the linker script.

David