|Books on Debuggers firstname.lastname@example.org (2004-04-28)|
|Re: Books on Debuggers email@example.com (2004-04-29)|
|Re: Books on Debuggers firstname.lastname@example.org (Paul F. Dietz) (2004-04-29)|
|Re: Books on Debuggers email@example.com (Joe) (2004-04-29)|
|Re: Books on Debuggers firstname.lastname@example.org (glen herrmannsfeldt) (2004-05-02)|
|Re: Books on Debuggers email@example.com (2004-05-02)|
|Re: Books on Debuggers firstname.lastname@example.org (2004-05-08)|
|Re: Books on Debuggers email@example.com (Tim Bauer) (2004-05-08)|
|Re: Books on Debuggers firstname.lastname@example.org (2004-05-16)|
|From:||"Tim Bauer" <email@example.com>|
|Date:||8 May 2004 21:09:22 -0400|
|Organization:||Cal Poly, SLO|
|References:||04-04-090 04-04-103 04-05-009|
|Posted-Date:||08 May 2004 21:09:22 EDT|
> >>Could anyone please recommend any good books on how to write a debugger?
How Debuggers Work : Algorithms, Data Structures, and Architecture
by Jonathan B. Rosenberg
I have not read this book, but it is one of the first books I have
seen that covers such a topic. However, I have not read it and cannot
tell if it is good or not.
"How to write a debugger" is quite a system dependent creation as has been
Here are a few of my favorite examples of debugger magic (GNU gdb
debugging C on Intel architecture (probably many others too):
- Breakpoints: Breakpoints are special instructions that trap into the OS
to "stop the train" if it is running full speed". I am not sure if
there is an explicit instruction or if it a regualar software
interrupt (the net effect is the same).
By inserting a breakpoint, you are inserting an instruction into
the text of the user's program.
- Watchpoints: A hardware watchpoint changes access to the memory page that
a variable is on.
When something trys to read or write memory on that page, the debugger
catches the memory violation and
handles it transparently. If it is the watched variable, it notifies you.
- Stacktraces: Stack frames have a reasonably well behaved structure. By
walking down the stack and reading
return addresses you can get a list of "where you have been". Further,
you can resolve runtime addresses with
debugging information out of the object files (if it is present) and get
line mapping info.
Much of the rest of a debugger is sugar coating. It is very nice to
break at a breakpoint only if some expression is true. So break there,
have the debugger test the expression, and if true, really break.
A debugger is allowed to (and must) make some assumptions that the
program being debugged is well behaved. Therefore, you can easily
confound your debugger with self modifying code or unplanned stack
Debuggers are a wonderful set of kludges and hacks that make life
liveable. In designing and writing one, you really want to know your
archritecture and OS inside and out. Many features, will require close
collaboration between OS and arch.
Return to the
Search the comp.compilers archives again.