Re: 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 > wrote:


Thomas Jakway > 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/326931db9cdc26f2d47657c1f084b9903fd46246



___
ghc-devs mailing list
ghc-devs@haskell.org 
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs





___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Debugging GHC with GHCi

[Simon Marlow]

On 9 January 2017 at 04:51, Ben Gamari  wrote:

> Thomas Jakway  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@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Debugging GHC with GHCi

[Ben Gamari]

Thomas Jakway  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].

Cheers,

- Ben


[1] https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e
[2] 
http://git.haskell.org/ghc.git/commit/326931db9cdc26f2d47657c1f084b9903fd46246


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Debugging GHC with GHCi

[Richard Eisenberg]

> On Jan 8, 2017, at 8:33 PM, Thomas Jakway  wrote:
> 
> Currently I'm using trace & friends to do printf-style debugging but it's 
> definitely not ideal.

I don't have an answer to your question, but I can tell you that this is 
exactly what I do. It's not ideal at all. If you figure out how to do this, 
tell us!

Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs