digitalmars.D.bugs - [Issue 4014] New: CodeView debug type info not linked in from library
- d-bugmail puremagic.com (41/41) Mar 27 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4014
- d-bugmail puremagic.com (25/25) Mar 27 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4014
- d-bugmail puremagic.com (13/13) Feb 07 2011 http://d.puremagic.com/issues/show_bug.cgi?id=4014
- d-bugmail puremagic.com (22/22) Feb 13 2011 http://d.puremagic.com/issues/show_bug.cgi?id=4014
- d-bugmail puremagic.com (7/7) Sep 20 2011 http://d.puremagic.com/issues/show_bug.cgi?id=4014
- d-bugmail puremagic.com (11/11) Sep 12 2012 http://d.puremagic.com/issues/show_bug.cgi?id=4014
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
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
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
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
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
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