Re: Books on Debuggers

"Tim Bauer" <tbauer@cadrc.calpoly.edu>
8 May 2004 21:09:22 -0400

          From comp.compilers

Related articles
Books on Debuggers napi@cs.indiana.edu (2004-04-28)
Re: Books on Debuggers nmm1@cus.cam.ac.uk (2004-04-29)
Re: Books on Debuggers dietz@dls.net (Paul F. Dietz) (2004-04-29)
Re: Books on Debuggers joe@burgershack.net (Joe) (2004-04-29)
Re: Books on Debuggers gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-05-02)
Re: Books on Debuggers jcai@orcca.on.ca (2004-05-02)
Re: Books on Debuggers nmm1@cus.cam.ac.uk (2004-05-08)
Re: Books on Debuggers tbauer@cadrc.calpoly.edu (Tim Bauer) (2004-05-08)
Re: Books on Debuggers thp@cs.ucr.edu (2004-05-16)
| List of all articles for this month |
From: "Tim Bauer" <tbauer@cadrc.calpoly.edu>
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
suggested.


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
manipulation.


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.