Changes between Version 6 and Version 7 of GhciDebugger

Oct 25, 2006 11:10:55 AM (9 years ago)

Added missing important information about dynamic breakpoints


  • GhciDebugger

    v6 v7  
    1 = Work in Progress =
    24= Report of the implementation of the GHCi debugger =
    35During the Summer of 2006 I have been working on this project sponsorized by the[ Google SoC] initiative. My mentors were Simon Marlow and David Himmelstrup (lemmih).
    168170= Dynamic Breakpoints =
    169171The approach followed here has been the well known 'do the simplest thing that could possibly work'. We instrument the code with 'auto' breakpoints at event ''sites''. Currently event sites are code locations where names are bound, and statements:
    170  * let declarations
    171  * where declarations
    172  * top level declarations
    173  * case alternatives
    174  * lambda abstractions
     172 * Binding sites (top level, let/where local bindings, case alternatives, lambda abstractions, etc.)
    175173 * do statements (any variant of them)
    177175The instrumentation is done at the desugarer too, which has been extended accordingly. We distinguish between 'auto' breakpoints, those introduced by the desugarer, and 'normal' breakpoints user created by using the `breakpoint` function directly.
     177== The D in Dynamic Breakpoints ==
     178When we instrument the code we insert a flavor of regular breakpoints which know about their site number. So when one of these is hit, ghci finds out whether that site is enabled and acts accordingly.
     179GHCi thus stores a boolean matrix of enabled breakpoint sites. This scheme is realized in [ Breakpoints.hs]:
     181data BkptTable a  = BkptTable {
     182     breakpoints :: Map.Map a (UArray Int Bool)  -- *An array of breaks, indexed by site number
     183   , sites       :: Map.Map a [[(SiteNumber, Int)]] -- *A list of lines, each line can have zero or more sites, which are annotated with a column number
     184   }
     187Since this structure needs to be accessed every time a breakpoint is hit and is modified extremely few times in comparison, the goal is to have as fast access time as possible. Most of the overhead is due to this structure.
     188It's too bad that I haven't explored alternative designs. (Using bits instead of Bools in the matrix? discard the matrix thing and use an IORef in every breakpoint? some clever trick using the FFI?).
    179190== Overhead ==