ghc/docs/comm/the-beast/ghci.html

   1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
   2 <html>
   3   <head>
   4     <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
   5     <title>The GHC Commentary - GHCi</title>
   6   </head>
   7
   8   <body BGCOLOR="FFFFFF">
   9     <h1>The GHC Commentary - GHCi</h1>
  10
  11     This isn't a coherent description of how GHCi works, sorry.  What
  12     it is (currently) is a dumping ground for various bits of info
  13     pertaining to GHCi, which ought to be recorded somewhere.
  14
  15     <h2>Debugging the interpreter</h2>
  16
  17     The usual symptom is that some expression / program crashes when
  18     running on the interpreter (commonly), or gets wierd results
  19     (rarely).  Unfortunately, finding out what the problem really is
  20     has proven to be extremely difficult.  In retrospect it may be
  21     argued a design flaw that GHC's implementation of the STG
  22     execution mechanism provides only the weakest of support for
  23     automated internal consistency checks.  This renders it hard to
  24     debug.
  25     <p>
  26     Execution failures in the interactive system can be due to
  27     problems with the bytecode interpreter, problems with the bytecode
  28     generator, or problems elsewhere.  From the bugs seen so far,
  29     the bytecode generator is often the culprit, with the interpreter
  30     usually being correct.
  31     <p>
  32     Here are some tips for tracking down interactive nonsense:
  33     <ul>
  34       <li>Find the smallest source fragment which causes the problem.
  35       <p>
  36       <li>Using an RTS compiled with <code>-DDEBUG</code> (nb, that
  37           means the RTS from the previous stage!), run with <code>+RTS
  38           -D2</code> to get a listing in great detail from the
  39           interpreter.  Note that the listing is so voluminous that
  40           this is impractical unless you have been diligent in
  41           the previous step.
  42       <p>
  43       <li>At least in principle, using the trace and a bit of GDB
  44           poking around at the time of death, you can figure out what
  45           the problem is.  In practice you quickly get depressed at
  46           the hopelessness of ever making sense of the mass of
  47           details.  Well, I do, anyway.
  48       <p>
  49       <li><code>+RTS -D2</code> tries hard to print useful
  50           descriptions of what's on the stack, and often succeeds.
  51           However, it has no way to map addresses to names in
  52           code/data loaded by our runtime linker.  So the C function
  53           <code>ghci_enquire</code> is provided.  Given an address, it
  54           searches the loaded symbol tables for symbols close to that
  55           address.  You can run it from inside GDB:
  56       <pre>
  57       (gdb) p ghci_enquire ( 0x50a406f0 )
  58       0x50a406f0 + -48  ==  `PrelBase_Czh_con_info'
  59       0x50a406f0 + -12  ==  `PrelBase_Izh_static_info'
  60       0x50a406f0 + -48  ==  `PrelBase_Czh_con_entry'
  61       0x50a406f0 + -24  ==  `PrelBase_Izh_con_info'
  62       0x50a406f0 +  16  ==  `PrelBase_ZC_con_entry'
  63       0x50a406f0 +   0  ==  `PrelBase_ZMZN_static_entry'
  64       0x50a406f0 + -36  ==  `PrelBase_Czh_static_entry'
  65       0x50a406f0 + -24  ==  `PrelBase_Izh_con_entry'
  66       0x50a406f0 +  64  ==  `PrelBase_EQ_static_info'
  67       0x50a406f0 +   0  ==  `PrelBase_ZMZN_static_info'
  68       0x50a406f0 +  48  ==  `PrelBase_LT_static_entry'
  69       $1 = void
  70       </pre>
  71          In this case the enquired-about address is
  72          <code>PrelBase_ZMZN_static_entry</code>.  If no symbols are
  73          close to the given addr, nothing is printed.  Not a great
  74          mechanism, but better than nothing.
  75       <p>
  76       <li>We have had various problems in the past due to the bytecode
  77           generator (<code>compiler/ghci/ByteCodeGen.lhs</code>) being
  78           confused about the true set of free variables of an
  79           expression.  The compilation scheme for <code>let</code>s
  80           applies the BCO for the RHS of the let to its free
  81           variables, so if the free-var annotation is wrong or
  82           misleading, you end up with code which has wrong stack
  83           offsets, which is usually fatal.
  84       <p>
  85       <li>The baseline behaviour of the interpreter is to interpret
  86           BCOs, and hand all other closures back to the scheduler for
  87           evaluation.  However, this causes a huge number of expensive
  88           context switches, so the interpreter knows how to enter the
  89           most common non-BCO closure types by itself.
  90           <p>
  91           These optimisations complicate the interpreter.
  92           If you think you have an interpreter problem, re-enable the
  93           define <code>REFERENCE_INTERPRETER</code> in
  94           <code>ghc/rts/Interpreter.c</code>.  All optimisations are
  95           thereby disabled, giving the baseline
  96           I-only-know-how-to-enter-BCOs behaviour.
  97       <p>
  98       <li>Following the traces is often problematic because execution
  99           hops back and forth between the interpreter, which is
 100           traced, and compiled code, which you can't see.
 101           Particularly annoying is when the stack looks OK in the
 102           interpreter, then compiled code runs for a while, and later
 103           we arrive back in the interpreter, with the stack corrupted,
 104           and usually in a completely different place from where we
 105           left off.
 106           <p>
 107           If this is biting you baaaad, it may be worth copying
 108           sources for the compiled functions causing the problem, into
 109           your interpreted module, in the hope that you stay in the
 110           interpreter more of the time.  Of course this doesn't work
 111           very well if you've defined
 112           <code>REFERENCE_INTERPRETER</code> in
 113           <code>ghc/rts/Interpreter.c</code>.
 114       <p>
 115       <li>There are various commented-out pieces of code in
 116           <code>Interpreter.c</code> which can be used to get the
 117           stack sanity-checked after every entry, and even after after
 118           every bytecode instruction executed.  Note that some
 119           bytecodes (<code>PUSH_UBX</code>) leave the stack in
 120           an unwalkable state, so the <code>do_print_stack</code>
 121           local variable is used to suppress the stack walk after
 122           them.
 123     </ul>
 124
 125
 126     <h2>Entering and returning between interpreted and compiled code</h2>
 127
 128
 129     <p><small>
 130 <!-- hhmts start -->
 131 Last modified: Fri Feb  1 16:14:11 GMT 2002
 132 <!-- hhmts end -->
 133     </small>
 134   </body>
 135 </html>