Debugging GHC with GHCi

[Simon Marlow]

On 9 January 2017 at 04:51, Ben Gamari <ben at smart-cactus.org> wrote:

> Thomas Jakway <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
> [2] http://git.haskell.org/ghc.git/commit/326931db9cdc26f2d47657c1f084b9
> 903fd46246
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> 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/20170109/e5e3e8a1/attachment.html>