Loading GHC into GHCi (reprise)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Loading GHC into GHCi (reprise)

Erik de Castro Lopo-34
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.

Anyone have any idea why this doesn't work?

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (reprise)

Erik de Castro Lopo-34
Erik de Castro Lopo wrote:

> I even tied adding `-icompiler/llvmGen` to the above command line (from
> hell) before I noticed that it was already present.

Well I have a solution, I modified the module export list as follows:

    -module LlvmCodeGen ( llvmCodeGen, llvmFixupAsm ) where
    +module LlvmCodeGen ( llvmFixupAsm, module LlvmCodeGen ) where
 
which gives me access to all top level functions in that module.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (reprise)

Ben Gamari-3
In reply to this post by Erik de Castro Lopo-34
Erik de Castro Lopo <[hidden email]> 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



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
Erik de Castro Lopo <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;mle+hs@mega-nerd.com&#39;)">mle+hs@...> 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



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (reprise)

Ben Gamari-3
Ccing Edward, who may have some insight here.


Carter Schonwald <[hidden email]> 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 ??
>
It does not work as far as I know. I don't believe the problem was ever
that -fobject-code wasn't a dynamic flag; I suspect the reason is that
by the time we see the pragma we've already committed to compiling the
module. That being said, I'm not as familiar with this part of the
compiler as I'd like to be.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (reprise)

Ben Gamari-3
In reply to this post by Carter Schonwald
Carter Schonwald <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (reprise)

Thomas Miedema
In reply to this post by Ben Gamari-3


On Wed, Mar 9, 2016 at 7:33 PM, Ben Gamari <[hidden email]> wrote:
Unfortunately -fobject-code is necessary when loading GHC in GHCi as the
bytecode interpreter doesn't support unboxed tuples, which various GHC
modules use.

There's a ticket for that: https://ghc.haskell.org/trac/ghc/ticket/1257 ("Bytecode generator can't handle unboxed tuples"). Fixing that would make it much easier to use GHCi to load the compiler, and allow setting breakpoints, make a change and use `:r` to reload etc. The ticket is closed as wontfix however.




_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs