<p><br>
On Sep 2, 2013 1:26 AM, "Jonathan M Davis" <<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>> wrote:<br>
><br>
> On Sunday, September 01, 2013 17:14:01 H. S. Teoh wrote:<br>
> > Well, I'm not an IDE person, so I have nothing to say on that front.<br>
> ><br>
> > But I will say that debugging can and must be improved. Currently, about<br>
> > the only thing usable for dmd -g is to get a stacktrace of a program<br>
> > crash. Nothing else seems to be properly supported (I use gdb). Stepping<br>
> > through statements and setting breakpoints more-or-less works, but I<br>
> > can't get at most variables (keeps complains about being unable to<br>
> > reference 'this' or something similar), sometimes variable values are<br>
> > outright wrong or completely unrelated to the actual value, sometimes<br>
> > variables shown right on the source line being debugged don't exist in<br>
> > the debugger ('no such symbol'). Unable to look into nested structs<br>
> > without hitting odd behaviour. Doesn't understand D naming conventions<br>
> > (or does so poorly).<br>
> ><br>
> > Basically, I've given up trying to use gdb on D programs except when I<br>
> > need to find out where a crash is happening. Using writeln debugging is<br>
> > far more productive, sadly to say. I can imagine this state of affairs<br>
> > is quite disappointing to many potential D adopters.<br>
><br>
> This more or less mirrors my sentiments. I use (g)vim pretty much exclusively,<br>
> so I don't really care about IDEs aside from how they help the community at<br>
> large (your typical IDE's editing capabilites are so much of a joke compared<br>
> to those of vim, that using an IDE really makes no sense for editing - for me<br>
> at least).<br>
><br>
> However, I would definitely like improved debugger support. I almost always end<br>
> up using writeln debugging except when I need to track down a segfault. Of<br>
> course, gdb support for _C++_ sucks in my experience. It can't understand<br>
> basic stuff like operator overloading. So, I wouldn't expect much from D<br>
> support either - though it would be really nice if gdb could at least<br>
> understand D strings. I certainly wouldn't be opposed to someone writing a<br>
> solid debugger which was D-centric, as it would really improve debugging, but<br>
> I'm not holding my hopes up at this point. That's a major undertaking.<br>
><br>
> - Jonathan M Davis<br></p>
<p>I thought the problem with D strings was dmd, not gdb. As gdb has basic debugging capability with D (from experience with gdc).  Such as the ability to set breakpoints using pretty names, and it also recognises D arrays and prints them out in a pretty manner too.  Ie:  {1, 2, 3} and not {.length=3, .ptr=0x7ffff7ed0ff0}  (it does this by probing the type fields, if it sees a two field struct with the member names length and ptr then it works.  If it sees a ulong (see ABI page for dmd) then it will print you a ulong value.</p>

<p>If anyone has any suggestions for improving gdb support, just let me know as I intend to get round to improving some bits and pieces here and there someday.</p>
<p>Regards<br>
-- <br>
Iain Buclaw</p>
<p>*(p < e ? p++ : p) = (c & 0x0f) + '0';</p>