From: sewardj Date: Mon, 4 Feb 2002 12:15:39 +0000 (+0000) Subject: [project @ 2002-02-04 12:15:39 by sewardj] X-Git-Tag: Approximately_9120_patches~173 X-Git-Url: http://git.megacz.com/?a=commitdiff_plain;h=5ed6149dfbda444716d111aa76cf341ff0e48dc0;p=ghc-hetmet.git [project @ 2002-02-04 12:15:39 by sewardj] Start to record some stuff about GHCi. --- diff --git a/ghc/docs/comm/index.html b/ghc/docs/comm/index.html index f18713c..e38f713 100644 --- a/ghc/docs/comm/index.html +++ b/ghc/docs/comm/index.html @@ -57,6 +57,7 @@

The Evil Mangler

Alien Functions

The Native Code Generator +

GHCi

RTS & Libraries

diff --git a/ghc/docs/comm/the-beast/ghci.html b/ghc/docs/comm/the-beast/ghci.html new file mode 100644 index 0000000..c6eea8d --- /dev/null +++ b/ghc/docs/comm/the-beast/ghci.html @@ -0,0 +1,135 @@ + + + + + The GHC Commentary - GHCi + + + +

The GHC Commentary - GHCi

+ + This isn't a coherent description of how GHCi works, sorry. What + it is (currently) is a dumping ground for various bits of info + pertaining to GHCi, which ought to be recorded somewhere. + +

Debugging the interpreter

+ + The usual symptom is that some expression / program crashes when + running on the interpreter (commonly), or gets wierd results + (rarely). Unfortunately, finding out what the problem really is + has proven to be extremely difficult. In retrospect it may be + argued a design error that GHC's implementation of the STG + execution mechanism provides only the weakest of support for + automated internal consistency checks. This renders it hard to + debug and, essentially, unverifiable. +

+ Execution failures in the interactive system can be due to + problems with the bytecode interpreter, problems with the bytecode + generator, or problems elsewhere. From the bugs seen so far, + the bytecode generator is often the culprit, with the interpreter + usually being correct. +

+ Here are some tips for tracking down interactive nonsense: +

Find the smallest source fragment which causes the problem. +
+
Using an RTS compiled with -DDEBUG (nb, that + means the RTS from the previous stage!), run with +RTS + -D2 to get a listing in great detail from the + interpreter. Note that the listing is so voluminous that + this is impractical unless you have been diligent in + the previous step. +
+
At least in principle, using the trace and a bit of GDB + poking around at the time of death, you can figure out what + the problem is. In practice you quickly get depressed at + the hopelessness of ever making sense of the mass of + details. Well, I do, anyway. +
+

+RTS -D2 tries hard to print useful + descriptions of what's on the stack, and often succeeds. + However, it has no way to map addresses to names in + code/data loaded by our runtime linker. So the C function + ghci_enquire is provided. Given an address, it + searches the loaded symbol tables for symbols close to that + address. You can run it from inside GDB: +

+      (gdb) p ghci_enquire ( 0x50a406f0 )
+      0x50a406f0 + -48  ==  `PrelBase_Czh_con_info'
+      0x50a406f0 + -12  ==  `PrelBase_Izh_static_info'
+      0x50a406f0 + -48  ==  `PrelBase_Czh_con_entry'
+      0x50a406f0 + -24  ==  `PrelBase_Izh_con_info'
+      0x50a406f0 +  16  ==  `PrelBase_ZC_con_entry'
+      0x50a406f0 +   0  ==  `PrelBase_ZMZN_static_entry'
+      0x50a406f0 + -36  ==  `PrelBase_Czh_static_entry'
+      0x50a406f0 + -24  ==  `PrelBase_Izh_con_entry'
+      0x50a406f0 +  64  ==  `PrelBase_EQ_static_info'
+      0x50a406f0 +   0  ==  `PrelBase_ZMZN_static_info'
+      0x50a406f0 +  48  ==  `PrelBase_LT_static_entry'
+      $1 = void
+

+ In this case the enquired-about address is + PrelBase_ZMZN_static_entry. If no symbols are + close to the given addr, nothing is printed. Not a great + mechanism, but better than nothing. +

We have had various problems in the past due to the bytecode + generator (compiler/ghci/ByteCodeGen.lhs) being + confused about the true set of free variables of an + expression. The compilation scheme for lets + applies the BCO for the RHS of the let to its free + variables, so if the free-var annotation is wrong or + misleading, you end up with code which has wrong stack + offsets, which is usually fatal. +
+
The baseline behaviour of the interpreter is to interpret + BCOs, and hand all other closures back to the scheduler for + evaluation. However, this causes a huge number of expensive + context switches, so the interpreter knows how to enter the + most common non-BCO closure types by itself. +
+ These optimisations complicate the interpreter. + If you think you have an interpreter problem, re-enable the + define REFERENCE_INTERPRETER in + ghc/rts/Interpreter.c. All optimisations are + thereby disabled, giving the baseline + I-only-know-how-to-enter-BCOs behaviour. +
+
Following the traces is often problematic because execution + hops back and forth between the interpreter, which is + traced, and compiled code, which you can't see. + Particularly annoying is when the stack looks OK in the + interpreter, then compiled code runs for a while, and later + we arrive back in the interpreter, with the stack corrupted, + and usually in a completely different place from where we + left off. +
+ If this is biting you baaaad, it may be worth copying + sources for the compiled functions causing the problem, into + your interpreted module, in the hope that you stay in the + interpreter more of the time. Of course this doesn't work + very well if you've defined + REFERENCE_INTERPRETER in + ghc/rts/Interpreter.c. +
+
There are various commented-out pieces of code in + Interpreter.c which can be used to get the + stack sanity-checked after every entry, and even after after + every bytecode instruction executed. Note that some + bytecodes (PUSH_UBX) leave the stack in + an unwalkable state, so the do_print_stack + local variable is used to suppress the stack walk after + them. +

+ + +

Entering and returning between interpreted and compiled code

+ + +

+ +Last modified: Fri Feb 1 16:14:11 GMT 2002 + + + +