If a class is defined in a library, the debug info describing that class is not linked into an executable, if it does not reference the init-property.
Example:
----
module lib;
struct struc_lib
{
int a, b;
}
----
dmd -g -lib lib
----
module test;
import lib;
void main()
{
struc_lib slib;
}
----
dmd -g test lib.lib
----
This produces incomplete debug info for struc_lib.
Using
struc_lib slib = struc_lib.init;
helps.
Comment #1 by r.sagitario — 2010-03-27T01:38:36Z
This is caused the implicite "-multiobj" flag being set when compiling into a library. The debug type info is then in the module that contains the init-struct for the class/struct. If never referenced (e.g. if initialization is inlined), it will not show up in the executable.
A workaround is to not use -multiobj for libraries if they are compiled with debug info, but this can add some link dependencies.
Index: mars.c
===================================================================
--- mars.c (revision 419)
+++ mars.c (working copy)
@@ -806,7 +806,9 @@
global.params.objname = NULL;
// Haven't investigated handling these options with multiobj
- if (!global.params.cov && !global.params.trace)
+ // multiobj causes class/struct debug info to be attached to init-data,
+ // but this will not be linked into the executable, so this info is lost
+ if (!global.params.cov && !global.params.trace && !global.params.symdebug)
global.params.multiobj = 1;
}
else if (global.params.run)
Rainer Schuetze writes on the mailing list:
trying to create a branch with as little changes to the master branch as possible, I noticed that this patch causes problems when creating DLLs (it still wants _Dmain to be defined). This is happening because the patch puts full modules into a library instead of single functions when also adding debug symbols, so any reference into rt.dmain2 drags in the standard console application startup. My patches to create a shared version of the runtime library split this module, so the issue did not show up before.
I'd say the patch to 4014 should be reverted until this is sorted out. A minor improvement could be that prohibiting multiobj generation should be limited to debug builds in addition to adding debug symbols (which could also happen for release builds).
I just don't like the idea of duplicating the symbolic debug info. In reading this bug report, it seems the primary issue is that symdeb info is only generated for the module with the .init data.
A better solution may be to have a module generated with only symdeb info for a class, and a single global defined. Then, other modules can reference that single global, thereby pulling in the symdeb data.