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

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

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

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.

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"?

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:
#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!

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

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
>

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.

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