http://d.puremagic.com/issues/show_bug.cgi?id=4014

           Summary: CodeView debug type info not linked in from library
           Product: D
           Version: unspecified
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: r.sagitario@gmx.de


--- Comment #0 from Rainer Schuetze <r.sagitario@gmx.de> 2010-03-27 01:33:12 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4014



--- Comment #1 from Rainer Schuetze <r.sagitario@gmx.de> 2010-03-27 01:38:36 PDT ---
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)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4014


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |FIXED


--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> 2011-02-07 15:41:02 PST ---
https://github.com/D-Programming-Language/dmd/commit/86cfbb719175e7527605bc1a379e9d2205328b49

https://github.com/D-Programming-Language/dmd/commit/e921c3a7083a808cf1336de78d645757ff0f5d26

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4014


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2011-02-13 11:41:55 PST ---
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).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4014



--- Comment #4 from Rainer Schuetze <r.sagitario@gmx.de> 2011-09-20 23:44:42 PDT ---
This is a better patch:

https://github.com/D-Programming-Language/dmd/pull/398

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4014



--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2012-09-12 13:35:43 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------