Debugging GHC with GHCi

[Thomas Jakway]

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 <ben at smart-cactus.org 
> <mailto:ben at smart-cactus.org>> wrote:
>
>     Thomas Jakway <tjakway at nyu.edu <mailto:tjakway at nyu.edu>> 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 Main
>
> should 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
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170110/d7427ed9/attachment.html>