Debug Environments /
Win Dbg

To download WinDbg go to 
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx. 
To use it with D, compile with "-g". Then go to WinDbg and open the exe (Ctrl+E) 
and then open whatever source file your interested in (Ctrl+O). Set breakpoints, 
etc.

I've got a hobby project that's growing fairly rapidly in size, and I 
found the need to actually do some debugging with more than just writef. 
After digging around the forums, Windbg seemed like the best solution, 
since I don't have MSDEV/Visual Studio 6. I thought it might be a good 
idea to jot down some tips to save others some of the searching and 
experimenting I had to do. Please add more tips if you've got them!

1) You will need an early version of Windbg prior to 6.x, since MS 
changed the way it uses debugging information. DO NOT get any of the 
versions directly from the MS download pages, as they will not work. The 
version which comes on the Digital Mars C++ disc works with D.

If you have Windows XP, right-click on windbg.exe and select 
Properties->Version to check which version you've got. You can't use 
Help->About while running Windbg as this only displays the version of 
Windows you have, not the version of Windbg. The version that I found on 
the net (version 5.0 build 1719) defaults to displaying data in Hex 
format. This can be changed in the View->Options dialog under Debugger. 
However, for some reason the selection is not remembered between 
sessions in the default "untitled" workspace, at least on my system. But 
if you save the workspace for your debugging session, it will be 
remembered when reloading the workspace.

2) Compile/build your source with the -g and -debug switches, but do NOT 
use -O, -release, or -inline, as they will only make things difficult 
while debugging.

3) Things you can do with Windbg which alone make it worth using (at 
least for me): set breakpoints in your D source files, step over/into 
code which can follow into and open other source files, and watch most 
of the built-in types including static arrays and static (char[x]) 
strings and structs.

4) The types of data you CANNOT watch directly with Windbg are: dynamic 
arrays, associative arrays, classes, and top-level module variables. 
There may be others. I've had problems with static multi-dimensional 
string arrays, even though static multi-dimensional arrays of simple 
types display fine. Class functions can be stepped into and the local 
variables of the function display fine when in scope. However, class 
variables outside the scope of a function are not understood by Windbg.

There are some tricks for displaying these data types which Windbg has 
problems with. The best trick/kludge around this is setting up a debug{} 
block with local variables being assigned the data that Windbg can't 
understand. For example, if you've got an instance of a class named 
"hamburger" with some variables in that class called "ounces" and 
"cost", you can do this:

debug
{
   int h_ounces = hamburger.ounces;
   float h_cost = hamburger.cost;
}

These "debug variables" only exist in your executable when compiled with 
the -debug switch. When you compile without the -debug switch (even if 
you still use the -g switch) the entire debug{} block will be ignored.

One additional tip when using the debug{} block: use pointers for your 
debug variables and the values will be updated when the data you're 
really intending to watch is updated during execution. From the example 
above, use this instead:

debug
{
  int *h_ounces = &hamburger.ounces;
  float *h_cost = &hamburger.cost;
}

Now when you watch h_ounces and h_cost, the values pointed to will be 
updated in the watch window anytime hamburger.ounces or hamburger.cost 
changes during execution, just as if you were watching hamburger.ounces 
and hamburger.cost directly (but with the pointer dereference).

With these limitations, I can't really call Windbg good at debugging D 
programs, but it is *almost* good enough.