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.

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.

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