Actually that raises a question: is it possible to set a top level ghci option file pragma for having a module to fobject code ? That would be nice for exactly this reason. Fobject code doesn't seem to work as of 7.10, though it seems to be listed as dynamic as of 8.0 rc2, does that mean it'll work for those of using ghc 8.0 ?? On Wednesday, March 9, 2016, Ben Gamari wrote:

Erik de Castro Lopo javascript:;> 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

Carter Schonwald writes:

Actually that raises a question: is it possible to set a top level ghci option file pragma for having a module to fobject code ? That would be nice for exactly this reason. Fobject code doesn't seem to work as of 7.10, though it seems to be listed as dynamic as of 8.0 rc2, does that mean it'll work for those of using ghc 8.0 ??

For the record, I believe #1365 is a relevant ticket here. Cheers, - Ben