May 02, 2010
DMD currently outputs debug info differently depending on the switch you pass it. Currently it works as follows:

-g Act as D, using D extensions
-gc Act as C, no D extensions

This leads to an odd situation for debugging (here I focus on linux/other platforms that use DWARF, as my knowledge of debugging on windows is rather limited). Let's assume you're using a patched version of gdb or a sufficiently recent version from cvs/git.

Option 1: Compile with -g.

You fire up gdb with your crashing app. Oh look, gdb fails due to the D extensions to DWARF which aren't supported yet (unless the hypothetical app doesn't use dynamic arrays at all... what sort of app are you writing? :D).

Option 2: Compile with -gc.

You fire up gdb with your crashing app. Gdb recognises all your files end with .d and overrides the language setting, and gives you demangling and a nice debugging environment. However C doesn't support things like references, so all your classes appear as MyClass* rather than MyClass, same goes for all your functions with ref args (See bug #4149, this isn't the case yet, needs a small patch which I intend to write after this post).

Of course neither of these options are ideal, so I'm wondering what the correct way to proceed is. We have several options (in no particular order):

  * Add more -g* options

Eww. Doing this we could enable acting like D without D extensions, or acting like C++, or any number of other methods to get around the problems. On the other hand, there's more options to confuse the user, and they'll all be wondering why they have to compile with -gturnip rather than -g to get working debug info.

  * Remove the D extensions

We could remove the D extensions completely and stay within the spec. DWARF 4 is in drafting now, we could request the few features get added to the standard, then add in support when it's out. GCC is outputting some DWARF4 already by default as of 4.5, so users aren't going to complain about their ancient versions of gdb or other debuggers working. I think this is the best option, and would volunteer to poke the necessary people to get what we want in there.

  * Patch GDB

This needs someone who's familiar enough with gdb to write a patch, and it'll add ugliness to the source code from what I've seen of gdb's internals... I'm not sure such a patch would get included, even if it is possible to write one (I've just asked some gdb dev's, I'm awaiting a reply).

  * Change/replace the -gc option

Like the first option, but rather than adding a new -g* option, we replace -gc to use a language that supports more features, and go from there.

What I'm looking for is a consensus of some sort of what we think is the best way forward for the debugging situation in D. Do you have any better ideas than what I've suggested, or which of them do you think is the best way for us to proceed?

Thanks for your input,

Robert

May 02, 2010
On 5/2/2010 2:15 PM, Robert Clipsham wrote:
> DMD currently outputs debug info differently depending on the switch you pass it. Currently it works as follows:
> 
> -g Act as D, using D extensions
> -gc Act as C, no D extensions


>  * Change/replace the -gc option
> 
> Like the first option, but rather than adding a new -g* option, we replace -gc to use a language that supports more features, and go from there.

My vote would be something along the lines of:

-g == support as much of the language as can be squeezed into the native debug format.

-gd ==> add extensions to the native format to better suit d

Yes, it's not backwards compatible, but to date that's been so fragile on linux at least, that there's little to be compatible with.  I have no real idea what the state of debugging has been on windows as I don't use it.

Later,
Brad