Re: Loading GHC into GHCi (reprise)
On Wed, Mar 9, 2016 at 7:33 PM, Ben Gamari 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Loading GHC into GHCi (reprise)
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 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Loading GHC into GHCi (reprise)
Ccing Edward, who may have some insight here. 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 ?? > 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 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Loading GHC into GHCi (reprise)
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 > 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 > > > > :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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Loading GHC into GHCi (reprise)
Erik de Castro Lopo 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 > > :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
Re: Loading GHC into GHCi (reprise)
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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Loading GHC into GHCi (reprise)
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 :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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
