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.comAt 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