digitalmars.D.internals - Attempt to export ModuleInfo on Windows
- Rikki Cattermole (41/41) Nov 15 2022 Hello,
- Rikki Cattermole (24/24) Nov 18 2022 After doing some more work on my projects I ended up getting a
- Rikki Cattermole (2/2) Nov 25 2022 Related bug (that I of course encountered that fixing this would
Hello,
I'm having another attempt at solving ModuleInfo not being
exported on Windows.
This is an issue as it prevents D executable importing a D module
in a DLL.
So far I've managed to get exported and added to the
importedModules member, except:
Its being added as ``ModuleInfo**[]`` rather than
``ModuleInfo*[]``.
In dmodule.d ~364: ``Symbol* isym; /// Import version of csym``
In toobj.d ~190 in the importedModules handling:
```d
import std.algorithm : canFind;
if (mod.ident.toString().canFind("second")) {
if (!mod.isym) {
mod.isym = s.toImport(mod.loc);
outdata(mod.isym);
}
s = mod.isym;
//s.Sflags |= SFLweak;
dtb.xoff(s, 0, TYnptr);
} else {
/* Weak references don't pull objects in from the
library,
* they resolve to 0 if not pulled in by
something else.
* Don't pull in a module just because it was
imported.
*/
s.Sflags |= SFLweak;
dtb.xoff(s, 0, TYnptr);
}
```
And of course the export:
```d
objmod.export_symbol(m.csym, 0);
```
This is very frustrating, what should be quite simple, doesn't
appear to be easily solved (by me) and is a massive blocker.
Note: in my above code I am hard coding it to only apply to the
"second" module, to prevent needing to build druntime.
Nov 15 2022
After doing some more work on my projects I ended up getting a very interesting error message with ldc: ``` sidero_image-test-unittest.obj : error LNK2019: unresolved external symbol __imp__D6sidero4base4hash5utils12__ModuleInfoZ referenced in function ldc.dllimport_relocation sidero_image-test-unittest.obj : error LNK2019: unresolved external symbol __imp__D6sidero4base4hash3fnv12__ModuleInfoZ referenced in function ldc.dllimport_relocatio ``` What is interesting about this little error is that it is referencing the DllImport symbols from a ldc function. Generated from [0]. It's doing additional patching on top of the OS linker which is effectively dereference and set at start of runtime. This kinda rules out that it is simply a limitation of dmd and instead is a conceptual problem at the system linker & codegen level. So what does this mean for dmd? Well, either we copy the solution from ldc or we do the patching as needed. I think patching as needed may be the best bet, but that means changing druntime in two places with an additional memory allocation when calling importedModules. [0] https://github.com/ldc-developers/ldc/blob/03e35c5ce57e665e89f5ee2efeaffe958ba815d4/gen/passes/DLLImportRelocation.cpp#L183
Nov 18 2022
Related bug (that I of course encountered that fixing this would enable fixing) https://issues.dlang.org/show_bug.cgi?id=6019
Nov 25 2022








Rikki Cattermole <alphaglosined gmail.com>