www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - debugging on Mac OSX

reply "Daniel Davidson" <nospam spam.com> writes:
Ho do you debug D executables on mac os x in which debug symbols 
are available (preferably a setup that works in emacs with gdb or 
gud-gdb)?

This thread seems to bring up the issue I am seeing:

http://forum.dlang.org/thread/k55tiv$28u3$1 digitalmars.com

but no solution is provided. Also, this bug,

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

seems to specifically talk to the issue and is closed RESOLVED 
FIXED. Yet I am unable to get it to work.

In this thread on usability of D dev environment from OSX, 
several people are having success developing D on OSX. Question 
is, do they debug and if so how? (hopefully not just print 
statements)

I am a switcher, just trying out the mac ecosystem. On ubuntu 
linux, for my rather small sample apps emacs (M-x gdb) just 
works, assuming I've built with rdmd specifying debug and that 
the command build only (to keep the binary). The symbols and line 
numbers are available.

Is there a setup for Mac that others are having success with?

Thanks
Dan
Apr 29 2013
next sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
On Monday, 29 April 2013 at 12:46:01 UTC, Daniel Davidson wrote:

 Ho do you debug D executables on mac os x in which debug 
 symbols are available (preferably a setup that works in emacs 
 with gdb or gud-gdb)?


there is no solid solution as far as i know. you can try build 
zerobugs debugger from sources or mac ports(fails for me due to 
some libs on mountain lion) which has GUI and supports D, but now 
abandoned.

but my way is just to build with -gc and run lldb like this.
$ cd to/your/app/workdir
$ lldb

 start appname
 run


...
(sry, not used for some time)

if it crashes you will get nice lldb output and so on. maybe one 
day someone will do a GUI tool for this or maybe there is already 
one idk...

unfortunately mac development is really PITA so i'm just using 
VisualD on windows, and then test changes on mac. also i have 
tried MonoD both on windows and mac but it has even more 
inconvenient than VisualD, doesn't(?) have debugger integration 
and its project and file organization just kills me though it has 
better code completion...
Apr 29 2013
parent reply 1100110 <1100110 gmail.com> writes:
On 04/29/2013 08:14 AM, evilrat wrote:

 On Monday, 29 April 2013 at 12:46:01 UTC, Daniel Davidson wrote:

 Ho do you debug D executables on mac os x in which debug symbols are
 available (preferably a setup that works in emacs with gdb or gud-gdb)?


 there is no solid solution as far as i know. you can try build zerobugs
 debugger from sources or mac ports(fails for me due to some libs on
 mountain lion) which has GUI and supports D, but now abandoned.
 
 but my way is just to build with -gc and run lldb like this.
 $ cd to/your/app/workdir
 $ lldb

 start appname
 run


 ...
 (sry, not used for some time)
 
 if it crashes you will get nice lldb output and so on. maybe one day
 someone will do a GUI tool for this or maybe there is already one idk...
 
 unfortunately mac development is really PITA so i'm just using VisualD
 on windows, and then test changes on mac. also i have tried MonoD both
 on windows and mac but it has even more inconvenient than VisualD,
 doesn't(?) have debugger integration and its project and file
 organization just kills me though it has better code completion...


In my opinion, don't even bother going to the zerobugs website.
It'll be a long, boring, annoying waste of time.
Apr 29 2013
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Monday, 29 April 2013 at 18:49:46 UTC, 1100110 wrote:

 In my opinion, don't even bother going to the zerobugs website.
 It'll be a long, boring, annoying waste of time.


i don't. zerobugs source is on codeplex
Apr 29 2013
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
were you able to use it ? if so on which platforms? and does it provide
anything beyond what cgdb does?

On Mon, Apr 29, 2013 at 5:41 PM, evilrat <evilrat666 gmail.com> wrote:


 On Monday, 29 April 2013 at 18:49:46 UTC, 1100110 wrote:


 In my opinion, don't even bother going to the zerobugs website.
 It'll be a long, boring, annoying waste of time.


 i don't. zerobugs source is on codeplex
Apr 29 2013
parent "evilrat" <evilrat666 gmail.com> writes:
On Tuesday, 30 April 2013 at 00:52:18 UTC, Timothee Cour wrote:

 were you able to use it ? if so on which platforms? and does it 
 provide
 anything beyond what cgdb does?

 On Mon, Apr 29, 2013 at 5:41 PM, evilrat <evilrat666 gmail.com> 
 wrote:


 On Monday, 29 April 2013 at 18:49:46 UTC, 1100110 wrote:


 In my opinion, don't even bother going to the zerobugs 
 website.
 It'll be a long, boring, annoying waste of time.


 i don't. zerobugs source is on codeplex




never used it myself. it's mainly for linux. and it depends on 
gtk2, so for ubuntu is no go, unless someone will port it to gtk3.
Apr 29 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-29 14:45, Daniel Davidson wrote:

 Ho do you debug D executables on mac os x in which debug symbols are
 available (preferably a setup that works in emacs with gdb or gud-gdb)?

 This thread seems to bring up the issue I am seeing:

 http://forum.dlang.org/thread/k55tiv$28u3$1 digitalmars.com

 but no solution is provided. Also, this bug,

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

 seems to specifically talk to the issue and is closed RESOLVED FIXED.
 Yet I am unable to get it to work.

 In this thread on usability of D dev environment from OSX, several
 people are having success developing D on OSX. Question is, do they
 debug and if so how? (hopefully not just print statements)

 I am a switcher, just trying out the mac ecosystem. On ubuntu linux, for
 my rather small sample apps emacs (M-x gdb) just works, assuming I've
 built with rdmd specifying debug and that the command build only (to
 keep the binary). The symbols and line numbers are available.

 Is there a setup for Mac that others are having success with?


See:

* http://d.puremagic.com/issues/show_bug.cgi?id=8172
* http://d.puremagic.com/issues/show_bug.cgi?id=8207

-- 
/Jacob Carlborg
Apr 29 2013
parent reply "Dan" <dbdavidson yahoo.com> writes:
On Monday, 29 April 2013 at 16:48:27 UTC, Jacob Carlborg wrote:

 On 2013-04-29 14:45, Daniel Davidson wrote:

 Ho do you debug D executables on mac os x in which debug 
 symbols are
 available (preferably a setup that works in emacs with gdb or 
 gud-gdb)?

 This thread seems to bring up the issue I am seeing:

 http://forum.dlang.org/thread/k55tiv$28u3$1 digitalmars.com

 but no solution is provided. Also, this bug,

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

 seems to specifically talk to the issue and is closed RESOLVED 
 FIXED.
 Yet I am unable to get it to work.

 In this thread on usability of D dev environment from OSX, 
 several
 people are having success developing D on OSX. Question is, do 
 they
 debug and if so how? (hopefully not just print statements)

 I am a switcher, just trying out the mac ecosystem. On ubuntu 
 linux, for
 my rather small sample apps emacs (M-x gdb) just works, 
 assuming I've
 built with rdmd specifying debug and that the command build 
 only (to
 keep the binary). The symbols and line numbers are available.

 Is there a setup for Mac that others are having success with?


 See:

 * http://d.puremagic.com/issues/show_bug.cgi?id=8172
 * http://d.puremagic.com/issues/show_bug.cgi?id=8207


Thanks. What is the takeaway? That it does not work and can not 
work until these two bugs are fixed? A simple "I don't think you 
can get there from here"?
Apr 29 2013
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
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 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 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:


}



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!
Apr 29 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-04-30 02:01, Timothee Cour wrote:


 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.

 }


How did you get this working?

-- 
/Jacob Carlborg
Apr 29 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-04-29 20:49, Dan wrote:


 Thanks. What is the takeaway? That it does not work and can not work
 until these two bugs are fixed? A simple "I don't think you can get
 there from here"?


At least these bugs need to be fixed to get demangled symbol names.

-- 
/Jacob Carlborg
Apr 29 2013