Re: How do debuggers work?

1. A symbol table. This consists of:


-- an information transfer mechanism between compilers and the debugger
      so the debugger can perform symbolic debugging. This includes PC-to-line
      correlation information, file names, symbol names, symbol types,
      addreses, lexical scoping, etc. This info is recorded in the image
      being debugged and is accessed through fields in the image header.


-- symbol resolution; parsing, binding, and evaluation. The symbol resolution
      algorithm is fairly generic, with special cases as needed to handle various
      language constructs. Expression parsing and evaluation is table-driven, as
      there are more language-dependent issues.


      The VAX VMS debugger supports 12 languages: Ada, Basic, BLISS, C, COBOL,
      DIBOL, FORTRAN, Macro, Pascal, PL/1, RPG, and SCAN.


2. An exception handling facility. The debugger is an exception handler; it
      fields all exceptions before they are seen by the program under
      debug, and decides what to do with them. Some exceptions are caused
      by the (buggy) program (e.g., an array bounds violation). Other
      exceptions are caused by the debugger itself, in order to implement
      certain features (all variations of step, breakpoints, watchpoints, etc.).


3. A user interface. Both character-cell-based (screen mode) and windows-based
      interfaces are available.


For more details on the VAX VMS debugger, see the article authored by Bert
Beander in one of the early ASPLOS proceedings (I don't have the exact
reference handy, but will try to find it). It describes the debugger as it
existed a while ago in more detail.


The internal architecture of the debugger has changed quite a bit since
the paper was written. Among the new things that have come about:


- multi-process debugging capability


- task support for Ada and DECthreads (a POSIX-compliant thread implementation)


- the 2-process debug configuration (separation of the debugger into an
    architecture-specific "kernel" and architecture-independent "main").
    This has numerous benefits; the most positive from the user standpoint
    is that this reduces the side-effects caused by debugging.


- the DECwindows interface.


Hope this helps.


-Jeff E. Nelson
-DEBUG Software Engineer
-Digital Equipment Corporation
-Internet: jnelson@gauche.zko.dec.com
--

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