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.
Cheers,
- 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