Loading GHC into GHCi (reprise)

[Carter Schonwald]

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 <ben at well-typed.com> wrote:

> Erik de Castro Lopo <mle+hs at mega-nerd.com <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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160309/460eb411/attachment.html>