[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 --- Comment #17 from Dlang Bot --- dlang/dmd pull request #15974 "fix issue 4071: improve support for shared runtime" was merged into master: - 1f4e7217e16b784684cd0e4992810fc686373b86 by Rainer Schuetze: fix issue 4071: improve support for shared runtime - register module info of clients and run module ctors/dtors - register .data section of clients with the GC https://github.com/dlang/dmd/pull/15974 --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Adam Wilson changed: What|Removed |Added Status|NEW |RESOLVED CC||flybo...@gmail.com Resolution|--- |FIXED --- Comment #16 from Adam Wilson --- Fixed with PR: https://github.com/dlang/dmd/pull/14849 --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 --- Comment #15 from Rainer Schuetze --- > Rainer's add options -exportall and -sharedlib to dmd That's pretty outdated, here is a reboot: https://github.com/dlang/dmd/pull/14849 --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071
--- Comment #14 from Walter Bright ---
Rainer's add options -exportall and -sharedlib to dmd
Index: backend/cdef.h
===
--- backend/cdef.h (revision 431)
+++ backend/cdef.h (working copy)
@@ -675,6 +675,7 @@
# define WFsaveds 0x2000 // use push/pop DS for far functions
# define WFdsnedgroup 0x4000 // DS != DGROUP
# define WFexe 0x8000 // generating code for Windows EXE
+# define WFexpall 0x1// generate export definition for all
symbols
char inline8087;/* 0: emulator
1: IEEE 754 inline 8087 code
Index: backend/cgobj.c
===
--- backend/cgobj.c (revision 431)
+++ backend/cgobj.c (working copy)
@@ -2285,16 +2285,20 @@
{ char *coment;
size_t len;
-coment = (char *) alloca(4 + 1 + (IDMAX + IDOHD) + 1); // allow extra byte
for mangling
+coment = (char *) alloca(4 + 1 + (2*IDMAX + IDOHD) + 1); // allow extra
byte for mangling
len = obj_mangle(s,[4]);
assert(len <= IDMAX + IDOHD);
-coment[1] = 0xA0; // comment class
-coment[2] = 2; // why??? who knows
-if (argsize >= 64) // we only have a 5 bit field
-argsize = 0;// hope we don't need callgate
-coment[3] = (argsize + 1) >> 1; // # words on stack
-coment[4 + len] = 0;// no internal name
-objrecord(COMENT,coment,4 + len + 1); // module name record
+coment[0] = 0x80; // comment type (no purge bit
set)
+coment[1] = 0xA0; // comment class
+coment[2] = 2; // why??? who knows
+if (argsize >= 64) // we only have a 5 bit field
+ argsize = 0;// hope we don't need callgate
+coment[3] = (argsize + 1) >> 1;// # words on stack
+if(config.wflags & WFexpall)
+ len += obj_mangle(s,coment+4+len); // workaround for linker
inconsistently removing first char
+else
+ coment[4 + len++] = 0; // no internal name
+objrecord(COMENT,coment,4 + len); // module name record
}
/
Index: backend/out.c
===
--- backend/out.c (revision 431)
+++ backend/out.c (working copy)
@@ -141,6 +141,8 @@
ty = s->ty();
if (ty & mTYexport && config.wflags & WFexpdef && s->Sclass != SCstatic)
obj_export(s,0);// export data definition
+else if(config.wflags & WFexpall && type_mangle(s->Stype))
+ obj_export(s,0);// export data definition
for (dt = dtstart; dt; dt = dt->DTnext)
{
//printf("dt = x%p, dt = %d\n",dt,dt->dt);
@@ -1436,6 +1438,8 @@
!(sfunc->Sclass == SCinline && !(config.flags2 & CFG2comdat)) &&
sfunc->ty() & mTYexport)
obj_export(sfunc,Poffset); // export function definition
+else if(config.wflags & WFexpall && type_mangle(sfunc->Stype))
+ obj_export(sfunc,Poffset); // export function definition
if (config.fulltypes)
cv_func(sfunc); // debug info for function
Index: glue.c
===
--- glue.c (revision 431)
+++ glue.c (working copy)
@@ -610,8 +610,11 @@
else if (strcmp(s->Sident, "main") == 0 && linkage == LINKc)
{
#if TARGET_WINDOS
-objextdef("__acrtused_con");// bring in C startup code
-obj_includelib("snn.lib"); // bring in C runtime library
+ objextdef("__acrtused_con");// bring in C startup code
+ if(global.params.sharedlib)
+ obj_includelib("snn_shared.lib"); // bring in shared part
of C runtime library
+ else
+ obj_includelib("snn.lib"); // bring in C runtime
library
#endif
s->Sclass = SCglobal;
}
Index: mars.c
===
--- mars.c (revision 431)
+++ mars.c (working copy)
@@ -165,7 +165,7 @@
#endif
fprintf(stdmsg, "\n");
fflush(stdmsg);
-//halt();
+halt();
}
global.errors++;
}
@@ -216,7 +216,7 @@
*/
void halt()
{
-#ifdef DEBUG
+#if 0 //def DEBUG
*(char*)0=0;
#endif
}
@@ -254,6 +254,7 @@
-debuglib=nameset symbolic debug library to name\n\
-defaultlib=name set default library to name\n\
-deps=filename write module dependencies to filename\n%s\
+ -exportall export any suitable public symbol\n\
-g add symbolic debug info\n\
-gcadd symbolic debug
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23658 --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=6019 --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=9816 --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23535 --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=22367 --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Imperatorn changed: What|Removed |Added CC||johan_forsberg_86@hotmail.c ||om --- Comment #13 from Imperatorn --- Any chance of this ever being solved? --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Paul Backus changed: What|Removed |Added Keywords||bounty --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Mike Parker changed: What|Removed |Added CC||aldac...@gmail.com --- Comment #12 from Mike Parker --- A bounty has been placed on this issue: https://www.flipcause.com/secure/cause_pdetails/ODcyMDE= --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Version|unspecified |D2 --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 d...@dawgfoto.de changed: What|Removed |Added CC||d...@dawgfoto.de --- Comment #11 from d...@dawgfoto.de 2012-01-17 23:56:24 PST --- I have recently done a ModuleInfo refactoring along this line. I'd like to avoid having to link in a static library. The planned ELF mechanism works like the following: - The compiler emits a static init function into each object, library or executable. This function is a comdat so every DLL or EXE will have a single init function. - _minfo_beg/_minfo_end and _deh_beg/_deh_end are made static symbols. - The init function registers it's modules/EH tables with a global function in druntime. There we create an entry and store additional data like TLS index and writeable segments for GC. - The module initialization must now only iterate over all dlls and initialize them in the order of registration. If we can figure out how to create a static init function the same mechanism should work for Windows. By splitting registration and initialization we should be able to perform module construction outside DllMain of. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 --- Comment #9 from Jacob Carlborg d...@me.com 2010-04-11 03:56:04 PDT --- Another question: since you have moved the module initialization into a new file and let every binary take care of its own initialization, couldn't that cause problems like circular dependencies that aren't detected? For example, two modules from two different libraries, each compiled into its own dll, which import the other module. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 --- Comment #8 from Jacob Carlborg d...@me.com 2010-04-09 02:26:03 PDT --- That may actually a better idea, to let every binary handle its own initialization. Then I guess there will be no problem with module constructors that are run when they shouldn't. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 --- Comment #7 from Rainer Schuetze r.sagita...@gmx.de 2010-04-08 14:29:59 PDT --- I'm not sure the way you did it on OSX is feasable on Windows aswell, because you might not have access to all the info in the DLLs (maybe it's possible if you export all necessary symbols in each DLL). But I guess it will not work for dynamically loaded DLLs. My implementation does not need a supervising function to run initializers, each binary just initializes the part it contains. I haven't done anything with respect to exception handling, but if I understand it correctly, the exception frames are local to the functions and binary they belong to, so they still are unwinded correctly. A simple test (catching an exception from inside phobos.dll) was working correctly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2010-04-07 11:40:36 PDT --- Created an attachment (id=600) add options -exportall and -sharedlib to dmd Let's start with a few patches to dmd: 1. add option -exportall to export any mangled symbol defined by an object file (a workaround for #3956 is needed, patching obj_export to avoid indeterministic removal of leading '_' from exported symbols by optlink) 2. add option -sharedlib to switch to different default libraries phobos_shared.lib and snn_shared.lib instead of phobos.lib and snn.lib -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 --- Comment #2 from Rainer Schuetze r.sagita...@gmx.de 2010-04-07 11:47:04 PDT --- Created an attachment (id=601) druntime support for building phobos.dll The major changes are in druntime and involve splitting files into the part that can be shared in a single DLL and the functions that must exist per binary: - move moduleCtor/Dtor, etc. from object_.di into new file moduleinit.d (had to copy some ModuleInfo (back?) declarations to object.di to compile) - move extern(C) main() from dmain2.d into new file cmain.d - exclude __LDBLULLNG() in llmath.d because it is already in snn.lib - build druntime.obj with -exportall instead of druntime.lib excluding moduleinit.d, cmain.d and a few more - extracted stuff from dll_helper.d into new file shared_dll_helper.d and added a few more functions to support patching relocations -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 --- Comment #3 from Rainer Schuetze r.sagita...@gmx.de 2010-04-07 11:54:49 PDT --- Created an attachment (id=602) changes to phobos to build phobos.dll The patches to phobos are more-or-less limited to the makefile and adding 2 files: - phobos: build phobos.obj with -exportall instead of phobos.lib - add def-file exporting any sensible symbol from the C compiled modules and snn.lib - add dllmain.d that works along the line of the new dll-support in dmd 2.042 - build phobos.dll from druntime.obj, C compiled modules and the object files not included in druntime.obj using the def-file - use implib to create import library phobos_shared.lib (the optlink /IMLIB creates a corrupted lib) - add modules to the lib that must exist in each binary: minit.obj, moduleinit.obj, cmain.obj, dll_helper.obj, etc. - extracted some modules from snn.lib (constart, dllstart, winstart, excptlst, cinit, ehinit, setargv, tlsdata, tlsseg, clearbss) and put them in new lib snn_shared.lib -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 --- Comment #4 from Rainer Schuetze r.sagita...@gmx.de 2010-04-07 12:00:45 PDT --- Created an attachment (id=603) example using the shared dll This is the example from dll.html modified to work with the shared DLL. Please note that an executable/DLL needs a slightly different initialization: - patch relocations to stubs to import table to the destination value to allow data symbols to be accessed correctly - do not init gc - inform gc about TLS usage - add check to module(tls)ctors to avoid calling modules in other dlls These are already covered by the patches to druntime. If you apply the patches, you might need to check the path to the tools at the top of the makefiles. current restrictions: - there is no global moduleinfo-array spanning all binaries - trace module not included (always produces output) - no version check, so welcome to DLL hell! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 --- Comment #5 from Rainer Schuetze r.sagita...@gmx.de 2010-04-07 12:15:59 PDT --- forgot to mention that the patches are against dmd rev 431, druntime rev 282 and phobos rev 1477. you can build the dll by executing make -f win32.mak dll in the phobos directory. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4071] Missing support to share memory and objects between DLLs and executable
http://d.puremagic.com/issues/show_bug.cgi?id=4071 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #6 from Jacob Carlborg d...@me.com 2010-04-07 13:08:02 PDT --- I have no experiences of DLLs but here are my experiences on converting Tango to a dynamic library on Mac OS X. Don't know if any of this would work on Windows. Comment 1 An option to build as an dynamic library would be nice Comment 2 The way I solved the problems here was to declare the D main function as a weak symbol in a C file. The module constructors are handled by looping through all loaded images (binaries, dynamic libraries) and collect the module info arrays. Then combining all the arrays into one and running all the module constructors. The same is done with the exception handling tables. The following have I not done yet, but I hope it will work: In a C file, declare a function to be a module initializer that initializes the D runtime if no D main function is present. Don't know if this helps anything. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
