[GHC] #11047: Provide call stacks in GHCi

[GHC]

#11047: Provide call stacks in GHCi
-------------------------------------+-------------------------------------
        Reporter:  simonmar          |                Owner:  simonmar
            Type:  task              |               Status:  new
        Priority:  high              |            Milestone:  8.0.1
       Component:  GHCi              |              Version:  7.11
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #545, #4837,      |  Differential Rev(s):  Phab:D1407,
  #11100                             |  Phab:D1595, Phab:D1747
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Simon Marlow <marlowsd@…>):

 In [changeset:"6be09e884730f19da6c24fc565980f515300e53c/ghc" 6be09e8/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="6be09e884730f19da6c24fc565980f515300e53c"
 Enable stack traces with ghci -fexternal-interpreter -prof

 Summary:
 The main goal here is enable stack traces in GHCi.  After this change,
 if you start GHCi like this:

   ghci -fexternal-interpreter -prof

 (which requires packages to be built for profiling, but not GHC
 itself) then the interpreter manages cost-centre stacks during
 execution and can produce a stack trace on request.  Call locations
 are available for all interpreted code, and any compiled code that was
 built with the `-fprof-auto` familiy of flags.

 There are a couple of ways to get a stack trace:

 * `error`/`undefined` automatically get one attached
 * `Debug.Trace.traceStack` can be used anywhere, and prints the current
   stack

 Because the interpreter is running in a separate process, only the
 interpreted code is running in profiled mode and the compiler itself
 isn't slowed down by profiling.

 The GHCi debugger still doesn't work with -fexternal-interpreter,
 although this patch gets it a step closer.  Most of the functionality
 of breakpoints is implemented, but the runtime value introspection is
 still not supported.

 Along the way I also did some refactoring and added type arguments to
 the various remote pointer types in `GHCi.RemotePtr`, so there's
 better type safety and documentation in the bridge code between GHC
 and ghc-iserv.

 Test Plan: validate

 Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd

 Subscribers: thomie

 Differential Revision: https://phabricator.haskell.org/D1747

 GHC Trac Issues: #11047, #11100
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11047#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler