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