Re: Books on Debuggers

"Tim Bauer" <>
8 May 2004 21:09:22 -0400

          From comp.compilers

Related articles
Books on Debuggers (2004-04-28)
Re: Books on Debuggers (2004-04-29)
Re: Books on Debuggers (Paul F. Dietz) (2004-04-29)
Re: Books on Debuggers (Joe) (2004-04-29)
Re: Books on Debuggers (glen herrmannsfeldt) (2004-05-02)
Re: Books on Debuggers (2004-05-02)
Re: Books on Debuggers (2004-05-08)
Re: Books on Debuggers (Tim Bauer) (2004-05-08)
Re: Books on Debuggers (2004-05-16)
| List of all articles for this month |

From: "Tim Bauer" <>
Newsgroups: comp.compilers
Date: 8 May 2004 21:09:22 -0400
Organization: Cal Poly, SLO
References: 04-04-090 04-04-103 04-05-009
Keywords: debug
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.

- Tim

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.