• Elronnd (20/20) Mar 13 2018 I'm trying to get programs run under ldc to run under lli. It
• Joakim (11/32) Mar 14 2018 As noted in the comment you linked, it's a magic linker symbol.
• David Nadlinger (10/13) Mar 14 2018 They are used in the global constructors implicitly created by the

Elronnd <elronnd elronnd.net> writes:

I'm trying to get programs run under ldc to run under lli.  It 
would always give me a message about missing __start___minfo, 
even when I told it to load shared libs.  I thought that might 
change with 1.8 giving the option to always link shared versions 
of phobos/druntime, but the same error pops up:

$ lli --load=/usr/lib/libphobos2-ldc-shared.so.78 
--load=/usr/lib/libdruntime-ldc-shared.so.78 test2.bc
LLVM ERROR: Program used external function '__start___minfo' 
which could not be resolved!

 From 
https://github.com/ldc-developers/ldc/blob/master/gen/modules.cpp#L379, it
appears to be used for metadata of modules?  Not sure why it wouldn't end up in
bitcode or why it wouldn't be accessible, but how can I get it?

I don't think that it's in an object file getting linked in 
because the linker command line is:

/usr/bin/gcc test2.o -o test2 -Xlinker --no-warn-search-mismatch 
-L/usr/lib -L/usr/lib/clang/5.0.1/lib/linux/ -lphobos2-ldc-shared 
-ldruntime-ldc-shared -Wl,--gc-sections -lrt -ldl -lpthread -lm 
-m64

Which doesn't seem to have anything in (beyond phobos/drt, which 
I'm already loading with lli) that would contain a 
__start___minfo.

Joakim <dlang joakim.fea.st> writes:

On Wednesday, 14 March 2018 at 06:32:43 UTC, Elronnd wrote:
 I'm trying to get programs run under ldc to run under lli.  It 
 would always give me a message about missing __start___minfo, 
 even when I told it to load shared libs.  I thought that might 
 change with 1.8 giving the option to always link shared 
 versions of phobos/druntime, but the same error pops up:

 $ lli --load=/usr/lib/libphobos2-ldc-shared.so.78 
 --load=/usr/lib/libdruntime-ldc-shared.so.78 test2.bc
 LLVM ERROR: Program used external function '__start___minfo' 
 which could not be resolved!

 From 
 https://github.com/ldc-developers/ldc/blob/master/gen/modules.cpp#L379, it
appears to be used for metadata of modules?  Not sure why it wouldn't end up in
bitcode or why it wouldn't be accessible, but how can I get it?

 I don't think that it's in an object file getting linked in 
 because the linker command line is:

 /usr/bin/gcc test2.o -o test2 -Xlinker 
 --no-warn-search-mismatch -L/usr/lib 
 -L/usr/lib/clang/5.0.1/lib/linux/ -lphobos2-ldc-shared 
 -ldruntime-ldc-shared -Wl,--gc-sections -lrt -ldl -lpthread -lm 
 -m64

 Which doesn't seem to have anything in (beyond phobos/drt, 
 which I'm already loading with lli) that would contain a 
 __start___minfo.

As noted in the comment you linked, it's a magic linker symbol.  
The linker normally adds the __start__minfo and __stop__minfo 
symbols to the __minfo section, along with similar delimiters for 
other sections, to allow code to access the beginning and end of 
the sections.  That accounts for how they're normally added, but 
I'm unsure of how they're normally accessed by D code, ie where 
they're required such that lli looks for them.

Your interpreter may need to account for the fact that those are 
normally added by the linker, or you could try to take out where 
they're being required in D code.

"David Nadlinger" <code klickverbot.at> writes:

On 14 Mar 2018, at 7:13, Joakim via digitalmars-d-ldc wrote:
 That accounts for how they're normally added, but I'm unsure of how 
 they're normally accessed by D code, ie where they're required such 
 that lli looks for them.

They are used in the global constructors implicitly created by the 
compiler to register the modules from each D executable/shared library 
with the runtime (passed to _d_dso_registry in rt.sections_elf_shared).

You can disable generation of ModuleInfo with LDC_no_moduleinfo (or 
-betterC), but then things depending on the runtime (like static this()) 
won't work. What the "proper" solution is depends significantly on how D 
modules (and global data in general) are mapped to your interpreter/JIT 
in terms of lifetime/reloading/…

  — David