Erik de Castro Lopo <mle...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
