summaryrefslogtreecommitdiff
path: root/compiler/main/Breakpoints.hs
Commit message (Collapse)AuthorAgeFilesLines
* Re-working of the breakpoint supportSimon Marlow2007-04-171-56/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the result of Bernie Pope's internship work at MSR Cambridge, with some subsequent improvements by me. The main plan was to (a) Reduce the overhead for breakpoints, so we could enable the feature by default without incurrent a significant penalty (b) Scatter more breakpoint sites throughout the code Currently we can set a breakpoint on almost any subexpression, and the overhead is around 1.5x slower than normal GHCi. I hope to be able to get this down further and/or allow breakpoints to be turned off. This patch also fixes up :print following the recent changes to constructor info tables. (most of the :print tests now pass) We now support single-stepping, which just enables all breakpoints. :step <expr> executes <expr> with single-stepping turned on :step single-steps from the current breakpoint The mechanism is quite different to the previous implementation. We share code with the HPC (haskell program coverage) implementation now. The coverage pass annotates source code with "tick" locations which are tracked by the coverage tool. In GHCi, each "tick" becomes a potential breakpoint location. Previously breakpoints were compiled into code that magically invoked a nested instance of GHCi. Now, a breakpoint causes the current thread to block and control is returned to GHCi. See the wiki page for more details and the current ToDo list: http://hackage.haskell.org/trac/ghc/wiki/NewGhciDebugger
* Improving the performance of breakpoints up to 50% (by playing with laziness)Pepe Iborra2007-02-211-3/+3
| | | | | | | | | | This patch performs several optimizations with the goal of minimizing the cost of building the arguments to breakpointJump: - Group them all in a single tuple, to minimize closure creation in heap - Wrap this with the GHC.Base.lazy combinator, to induce max laziness - Remove as many literal strings as possible * injecting a module-local CAF to store the module name and use that * eliminating the package string (not needed).
* Fix import listsPepe Iborra2006-12-201-1/+1
|
* Fix the buildIan Lynagh2006-12-161-1/+2
|
* Adjust code from manual mergesPepe Iborra2006-12-111-0/+2
|
* Handle breakpoint jumps while splicing TH functions in ghciPepe Iborra2006-12-101-0/+22
| | | | | | | | | | | | The dynamic linker has been modified so that it won't panic if one of the breakpointJump functions fails to resolve. Now, if the dynamic linker fails to find a HValue for a Name, before looking for a static symbol it will ask to Breakpoints.lookupBogusBreakpointVal :: Name -> Maybe HValue which returns an identity function for the Jump names or Nothing else. A TH function might contain a call to a breakpoint function. So if it is compiled to bytecodes, the breakpoints will be desugared to 'jumps'. Whenever this code is spliced, the linker will fail to find the jumpfunctions unless there is a default.
* Breakpoint code instrumentationPepe Iborra2006-12-101-0/+6
| | | | | | | | | | | | | Instrumentation gets activated by the '-fdebugging' dynflag. All the instrumentation occurrs in the desugarer; it consists of inserting 'breakpoint' combinators at a number of places in the AST, namely: - Binding sites - Do-notation statements These 'breakpoint' combinators will later be further desugared (at DsExpr) into ___Jump functions. For more info about this and all the ghci.debugger see the page at the GHC wiki: http://hackage.haskell.org/trac/ghc/wiki/GhciDebugger
* Extend the GHC API with breakpoints and breakpoint handlersPepe Iborra2006-12-101-0/+25
The entry point is: setBreakpointHandler :: Session -> BkptHandler Module -> IO ()