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
