Thanks very much, I'll give that a shot.
On 01/09/2017 08:12 AM, Simon Marlow wrote:
On 9 January 2017 at 04:51, Ben Gamari <[email protected] <mailto:[email protected]>> wrote:Thomas Jakway <[email protected] <mailto:[email protected]>> writes: > I want to be able to load certain GHC modules in interpreted mode in > ghci so I can set breakpoints in them. I have tests in the testsuite> that are compiled by inplace/bin/ghc-stage2 with -package ghc. I can> load the tests with ghc-stage2 --interactive -package ghc but since ghc> is compiled I can only set breakpoints in the tests themselves. Loading> the relevant files by passing them as absolute paths to :l loads them > but ghci doesn't stop at the breakpoints placed in them (I'm guessing > because ghci doesn't realize that the module I just loaded is meant to > replace the compiled version in -package ghc). > > So if I use > > inplace/bin/ghc-stage2 --interactive -package ghc mytest.hs > then > :l abs/path/to/AsmCodeGen.hs > > and set breakpoints, nothing happens. > Many of us would love to be able to load GHC into GHCi. Unfortunately, we aren't currently in a position where this is possible. The only thing standing in our way is the inability of GHC's interpreter to run modules which use unboxed tuples. While there are a few modules within GHC which use unboxed tuples, none of them are particularly interesting for debugging purposes, so compiling them with -fobject-code should be fine. In principle this could be accomplished by, {-# OPTIONS_GHC -fobject-code #-} However, as explained in #10965, GHC sadly does not allow this. I spent a bit of time tonight trying to see if I could convince GHC to first manually build object code for the needed modules, and then load bytecode for the rest. Unfortunately recompilation checking fought me at every turn. The current state of my attempt can be found here [1]. It would be great if someone could pick it up. This will involve, * Working out how to convince the GHC to use the object code for utils/Encoding.o instead of recompiling * Identifying all of the modules which can't be byte-code compiled and add them to $obj_modules * Chassing down whatever other issues that might pop up along the way I also wouldn't be surprised if you would need this GHC patch [2]. I would have thought that something like :set -fobject-code :load Main -- or whatever -- modify some source file :set -fbyte-code :load Mainshould do the right thing, loading object code when it can, up to the first module that has been modified more recently. Of course you can't have any object code modules that depend on byte-code modules, so if you modify something too low down in the dependency graph then you'll have a lot of interpreted modules, and you may end up trying to interpret something that can't be interpreted because it has an unboxed tuple. But for simple tests it ought to work. (I haven't tried this so I'm probably forgetting something...)Cheers Simon Cheers, - Ben [1] https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e <https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e> [2] http://git.haskell.org/ghc.git/commit/326931db9cdc26f2d47657c1f084b9903fd46246 <http://git.haskell.org/ghc.git/commit/326931db9cdc26f2d47657c1f084b9903fd46246> _______________________________________________ ghc-devs mailing list [email protected] <mailto:[email protected]> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
