[Issue 2741] gdb: debug symbols on OSX

[d-bugmail at puremagic.com]

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


Sean Kelly <sean at invisibleduck.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sean at invisibleduck.org


--- Comment #2 from Sean Kelly <sean at invisibleduck.org> 2011-01-12 15:03:44 PST ---
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: -------