Loading GHC into GHCi (reprise)

Ben Gamari ben at well-typed.com
Wed Mar 9 18:33:03 UTC 2016

Erik de Castro Lopo <mle+hs at mega-nerd.com> writes:

> Hi all,
> Recently Richard showed us how to load GHC into CHCi which ended up
> being documented here:
>     https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler
> That very useful for some things, but doesn't give you access to
> symbols and types that have not been exported.
> Specifically, I'm interested in some of the inner workings of the
> file `compiler/llvmGen/LlvmCodeGen.hs` and I've even managed to
> load it into GHCi using the command line:
>     inplace/bin/ghc-stage2 --interactive  -ignore-dot-ghci -fobject-code \
>        -DSTAGE=1 -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen \
>       -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn \
>       -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen \
>       -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename \
>       -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn \
>       -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils \
>       -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen \
>       -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/.  \
>       -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -XHaskell2010 \
>       compiler/llvmGen/LlvmCodeGen.hs
> and it loads all the modules require, but then seems to mess up the symbol
> table so that it can't even find top level functions in the module it has
> just loaded. 
>     Prelude LlvmCodeGen> :t LlvmCodeGen.cmmDataLlvmGens
>     <interactive>:1:1: error:
>         Not in scope: ‘LlvmCodeGen.cmmDataLlvmGens’
>         No module named ‘LlvmCodeGen’ is imported.
> I even tied adding `-icompiler/llvmGen` to the above command line (from
> hell) before I noticed that it was already present.
The issue here is that you used -fobject-code while loading the module
in question; this gives you only access to exported definitions.
Unfortunately -fobject-code is necessary when loading GHC in GHCi as the
bytecode interpreter doesn't support unboxed tuples, which various GHC
modules use.

I suspect it should be possible to convince GHCi to use object code for
those modules which require it. In fact, I think thomie was looking into
this at some point. I'm not sure what became of his effort.


- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160309/8aee0391/attachment.sig>

More information about the ghc-devs mailing list