www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windbg debugging tips

reply John Stoneham <captnjameskirk moc.oohay> writes:
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.

With these limitations, I can't really call Windbg good at debugging D 
programs, but it is *almost* good enough.
Feb 14 2006
next sibling parent reply Derek Parnell <derek psych.ward> writes:
Hope you don't mind but I've added these tips to the Wiki4D site.

  http://www.prowiki.org/wiki4d/wiki.cgi?DebugEnvironments


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
15/02/2006 11:14:49 AM
Feb 14 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:owgppkekm9qu.1svvurhsymevt$.dlg 40tude.net...

 Hope you don't mind but I've added these tips to the Wiki4D site.

  http://www.prowiki.org/wiki4d/wiki.cgi?DebugEnvironments


I was going to suggest that, but you beat me to it! This is ideal stuff for 
the wiki.
Feb 15 2006
parent reply John Stoneham <captnjameskirk moc.oohay> writes:
Walter Bright wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:owgppkekm9qu.1svvurhsymevt$.dlg 40tude.net...

 Hope you don't mind but I've added these tips to the Wiki4D site.

  http://www.prowiki.org/wiki4d/wiki.cgi?DebugEnvironments


 
 I was going to suggest that, but you beat me to it! This is ideal stuff for 
 the wiki. 
 
 


Thanks, I'll be updating the wiki with more tips as I find them. BTW, 
should I have not posted this here and just used the wiki instead?
Feb 15 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
John Stoneham wrote:

 Walter Bright wrote:
 

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:owgppkekm9qu.1svvurhsymevt$.dlg 40tude.net...


 Hope you don't mind but I've added these tips to the Wiki4D site.

  http://www.prowiki.org/wiki4d/wiki.cgi?DebugEnvironments



 I was going to suggest that, but you beat me to it! This is ideal 
 stuff for the wiki.


 
 Thanks, I'll be updating the wiki with more tips as I find them. BTW, 
 should I have not posted this here and just used the wiki instead?


IMHO, you did right!

Showing them here is probably the best thinkable place, and gets 
immediate attention with the crowd to whom it really matters.

That stuff get copied from here to the wiki is natural, the wiki then 
servers as a reference. -- Both for us and for lots of people who don't 
follow these NGs.
Feb 15 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"John Stoneham" <captnjameskirk moc.oohay> wrote in message 
news:dsv36u$t09$2 digitaldaemon.com...

 Thanks, I'll be updating the wiki with more tips as I find them. BTW, 
 should I have not posted this here and just used the wiki instead?


With the n.g., it's easy to see what's new but hard to find when it has 
scrolled off. The wiki is the opposite, it's organized and easy to find 
info, but hard to see what's new.

So I suggest that if it's not so large, put it in both places. If it's 
larger, post it in the wiki and put an announcement and link to it in the 
n.g.

If it isn't obvious, I think that wikis are one of the most marvellous 
inventions that the web has made possible.
Feb 15 2006
prev sibling parent John Stoneham <captnjameskirk moc.oohay> writes:
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 my original 
example, use this:
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.
Feb 15 2006