Game Development Reference
In-Depth Information
program. The debugger can use this information to figure out how to display the
contents of local and global variables and figure out what source code to display as
you step through the code. This doesn
t explain how the debugger stops the debugged
application cold in its tracks, however. That trick requires a little help from the CPU
and a special interrupt instruction. If you use Visual Studio and you are running on
an Intel processor, you can try this little program:
'
void main()
{
__asm int 3
}
You may have never seen a line of code that looks like this. The
__asm
keyword tells
the compiler that the rest of the line should be treated as an assembly language
instruction. Alternatively, you can follow the
__asm
keyword with curly braces.
Everything inside these curly braces is parsed as assembly. The
int 3
assembly state-
ment evokes the breakpoint interrupt. Without dragging you through all the gory
details of interrupt tables, it suffices to say that a program with sufficient privileges
can
interrupts so that when they are evoked, a special function is called. This
is almost exactly like registering a callback function, but it happens at a hardware
level. DOS-based games used to grab interrupts all the time to redirect functions
such as the mouse or display system to their own evil ends. Debuggers trap the
breakpoint interrupt, and whenever you set a breakpoint, the debugger overwrites
the opcodes, or the machine level instructions, at the breakpoint location with those
that correspond to
int 3
. When the breakpoint is hit, control is passed to the
debugger, and it puts the original instructions back. If you press the
“
trap
”
“
Step into
”
or
“
command, the debugger finds the right locations for a new breakpoint
and simply puts it there without you ever being the wiser.
Step over
”
Hard-Coded Breakpoints Are Cool
I
ve found it useful to add hard-coded breakpoints, like the one in the earlier
code example, to functions in the game. It can be convenient to set one to
make sure that if control ever passes through that section of code, the
debugger will always trap it. Be careful,
'
though! If a debugger
is not
present, the program may crash. There
s also a Windows function called
SetDebugBreak()
that does the same thing but is processor independent.
'
So now you have the most basic understanding of how a debugger does its work. It
has a mechanism to stop a running program in its tracks, and it uses a compiler and
linker-generated data file to present symbolic information to programmers.
