www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4014] New: CodeView debug type info not linked in from library

reply d-bugmail puremagic.com writes:
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



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: -------
Mar 27 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4014




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: -------
Mar 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Feb 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4014


Walter Bright <bugzilla digitalmars.com> changed:

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



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: -------
Feb 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4014




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: -------
Sep 20 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4014




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: -------
Sep 12 2012