| Table of contents of this page | |
|
|
WinDbg
Carlos Santander B. (October 8, 2004)
| 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. |
|
|
Some more tips from John Stoneham (February 14, 2006)
| 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. |
|
|
CDB
Cdb is the command line tool that works behind the scenes of Windbg. (See above section for download link)
You can directly interact with it from within Windbg through View->Command
Again, compile your files with -g and -debug, and to debug you simply pass the program name to cdb
>cdb your_program
It'll default to assembly mode, when you step through, it'll be assembly instructions, etc.
To switch to source mode, you need to give it a series of commands:
>l+l
>l+s
>l+t
>l+o
>.lines
You can't step through just yet, the compiler puts some initialization code before it starts your program .. so you should set a break point at your main() function, which will be _Dmain, and not main
>bp _Dmain
to let the debugger run until it hits your break point, give it the 'g' command
>g
it'll run until it hits your break point, from there, you can step through with
>p
or step inside with
>t
and it'll step through your source code (and show you the lines and line numbers)
you can see a list of all supported commands with a ?
>?