debugging on Mac OSX

Timothee Cour thelastmammoth at gmail.com
Mon Apr 29 17:01:26 PDT 2013


Having a proper debugging support of D programs on linux/OSX/windows should
be a top priority, as it makes bug fixing really hard.
I also spent some time with zerobugs route. It looks like a dead end and
its developer will most likely not put more effort into it.

Here's what I have:

A) default stacktraces on linux (ubuntu, if that matters): (dmd -g
test_hello.d which has an assert(0);){
no function name, no file, no line numbers:
core.exception.AssertError at tests.test_hello(6): Assertion failure
----------------
filename() [0x40fc16]
filename() [0x40d86d]
...
}

B) default stacktraces on OSX{
function name, but no file and no line numbers
core.exception.AssertError at tests.test_hello(9): Assertion failure
----------------
5   test                                0x000000010f6305a6 _d_assertm + 38
6   test                                0x000000010f61204a void
tests.test_hello.__assert(int) + 26
7   test                                0x000000010f612016 _Dmain + 42
8   test                                0x000000010f630e95 extern (C) int
rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void
runMain() + 33
...
}

C) stacktraces on OSX with some modifications I did involving wrapping
atos, etc: {

shows function name, full file, line numbers, and catches segfaults.
0  file: exception.d:356 pure @safe bool
std.exception.enforce!(bool).enforce(bool, lazy const(char)[],
immutable(char)[], ulong)
1  file: path/som_file.d:100 void util.some_function(int x)
...

Some problems:
in case of segfault, the very latest stack frame is missing (so we only
have the parent of the parent of the function that caused the segfault,
plus anything older).

in some rare cases we only have the file name but no file path information.

}

D) debugging on ubuntu:
gdb/cgdb works ok: file, line numbers, we can break on a un-mangled
function name.
However it seems name demangling is partial: I see stuff
like std.stdio.__T7writelnTAAyaZ.writeln() (_param_0=...); maybe it has
issues with templates.  Also, I have issue making info locals work, and it
doesn't understand full D syntax etc.

E) debugging on OSX with apple's gdb (apple ships an old gdb: 6.3.50):
shows full file path, line numbers, but no symbol demangling. Cannot break
on unmangled function name.

F) debugging on OSX with 7.5.1 (eg: brew install
https://raw.github.com/Homebrew/homebrew-dupes/master/gdb.rb){

* requires to be run with sudo or code-signing
* doesn't show file/line numbers; function names appear mangled, eg:
#1  0x000000010000104a in D5tests10test_hello8__assertFiZv ()

}



Conclusions:
stacktraces on OSX can be made to work almost perfectly (caveat: missing
last stack frame on segfault), but doesn't work at all on linux
gdb works well on linux, but not at all on OSX

If anyone has a setup that works better at least in some respect, please
let me know!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20130429/9bc7b233/attachment.html>


More information about the Digitalmars-d-learn mailing list