digitalmars.D.bugs - [Issue 2741] New: debug symbols on OSX
- d-bugmail puremagic.com (21/21) Mar 17 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2741
- d-bugmail puremagic.com (32/32) Mar 18 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2741
- d-bugmail puremagic.com (10/10) Oct 12 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2741
- d-bugmail puremagic.com (31/31) Jan 12 2011 http://d.puremagic.com/issues/show_bug.cgi?id=2741
- d-bugmail puremagic.com (11/15) Jan 13 2011 http://d.puremagic.com/issues/show_bug.cgi?id=2741
- d-bugmail puremagic.com (7/7) Jan 13 2011 http://d.puremagic.com/issues/show_bug.cgi?id=2741
- d-bugmail puremagic.com (7/7) Jan 13 2011 http://d.puremagic.com/issues/show_bug.cgi?id=2741
- d-bugmail puremagic.com (12/12) Jan 31 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2741
http://d.puremagic.com/issues/show_bug.cgi?id=2741
Summary: debug symbols on OSX
Product: D
Version: unspecified
Platform: PC
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: bugzilla digitalmars.com
ReportedBy: bugzilla digitalmars.com
There is a problem with debug symbols, namely source file paths, generated by
DMD on OS X. It seems that gdb cannot find any source files when debugging a
program compiled with DMD's -g (or -gc) switch, with a "no source file named
[whatever]" error, so setting breakpoints is impossible. GDC on OS X does not
have this problem. Some googling around has led me to discover that GNU gcc on
linux (not Apple gcc) also had this problem a few releases ago until it was
patched, caused by something to do with the pathnames used in the debug symbols
it generated, though I'm not sure of the technical details.
--
Mar 17 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2741
A few more details if it'll help. It appears that no symbol table is loaded at
all on Leopard, whether using the gdb supplied with XCode 2.5 (gdb-696) or
XCode 3.1 (gdb-962). On Tiger (gdb-696 only), the situation is a little better,
but not much. Using the gdb command "info sources" on a simple Tango "hello"
program lists the following (comiled with "dmd -g") on Tiger, which lists no D
source files at all:
/System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h,
/System/Library/Frameworks/System.framework/PrivateHeaders/machine/cpu_capabilities.h,
<command line>, <built-in>, /SourceCache/Libsystem/Libsystem-88.3.10//,
CommPageSymbols.st, {standard input}
Now, the same file compiled with GDC shows the following sources, with both
gdb-696 and gdb-962 on Leopard, and gdb-696 on Tiger (although the order is
different):
/System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h,
/System/Library/Frameworks/System.framework/PrivateHeaders/machine/cpu_capabilities.h,
<command line>, <built-in>, /SourceCache/Libsystem/Libsystem-88.3.10//,
CommPageSymbols.st, {standard input}, ../shared/rt/typeinfo/ti_C.d, critical.c,
arraycast.d, ../shared/rt/util/string.d, ../shared/rt/util/hash.d,
../shared/rt/util/console.d, ../shared/rt/typeinfo/ti_wchar.d,
../shared/rt/typeinfo/ti_void.d, ../shared/rt/typeinfo/ti_ushort.d,
../shared/rt/typeinfo/ti_uint.d, ../shared/rt/typeinfo/ti_ubyte.d,
../shared/rt/typeinfo/ti_short.d, ../shared/rt/typeinfo/ti_int.d,
../shared/rt/typeinfo/ti_dchar.d, ../shared/rt/typeinfo/ti_char.d,
../shared/rt/typeinfo/ti_byte.d, ../shared/rt/typeinfo/ti_Ashort.d,
../shared/rt/typeinfo/ti_Aint.d, ../shared/rt/typeinfo/ti_Ag.d,
../shared/rt/typeinfo/ti_AC.d, monitor.c, memory_dyld.c, memory.d,
/Users/obijohn/projects/d/tango/std/c/stdarg.di, lifetime.d, genobj.d,
gcc/unwind.d, gcc/deh.d, dgccmain2.d, cmain.d, cast.d, aaA.d,
/Users/obijohn/projects/d/hello.d
--
Mar 18 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2741
Leandro Lucarella <llucax gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |llucax gmail.com
Summary|debug symbols on OSX |gdb: debug symbols on OSX
Severity|normal |regression
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 12 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2741
Sean Kelly <sean invisibleduck.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sean invisibleduck.org
---
I've been digging into this a bit, and the problem appears to be Mach-O
related. From the ABI docs:
"When using the Stabs debugging format, the symbol table also holds debugging
information. When using DWARF, debugging information is stored in the image’s
corresponding dSYM file, specified by the uuid_command structure."
The standard location for the debug symbol file is:
"appname.dSYM/Contents/Resources/DWARF/appname"
And I've verified that at least some apps (like Valgrind) won't even look for
this file if a uuid_command structure isn't present in the executable, and they
won't use it if the UUIDs don't match between the two files. I'm still sorting
out how the debug info file is structured though. All I know so far is that it
isn't simply a copy of the executable. Perhaps the file only contains the
debug sections and no code?
Using nm to compare the symbols in a D vs. a C app, the only notable difference
is that the C app contains entries pointing to the executable path and the
object file:
00000000 - 00 0000 SO /Users/sean/test/
4d2e279c - 00 0001 OSO /var/folders/blah/-Tmp-//blah.o
At the moment, I'm hoping that the only issue is that DMD current'y doesn't
generate the uuid_command block, and that adding a uuid_command and duplicating
the executable into the proper dSYM location will be enough to make debug info
work. More experimentation to follow.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 12 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2741
Jacob Carlborg <doob me.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |doob me.com
At the moment, I'm hoping that the only issue is that DMD current'y doesn't
generate the uuid_command block, and that adding a uuid_command and duplicating
the executable into the proper dSYM location will be enough to make debug info
work. More experimentation to follow.
Probably not due to: http://d.puremagic.com/issues/show_bug.cgi?id=4154
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2741 --- I added the uuid_command and changed the section names yesterday and it still didn't work. Not sure yet what else is needed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 13 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2741 --- Ah, I didn't notice the offset problem after changing the section names. That's next I suppose. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 13 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2741
dawg dawgfoto.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |dawg dawgfoto.de
Resolution| |FIXED
https://github.com/D-Programming-Language/dmd/pull/631
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012









d-bugmail puremagic.com 