<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Thanks very much, I'll give that a shot.<br>
</p>
<br>
<div class="moz-cite-prefix">On 01/09/2017 08:12 AM, Simon Marlow
wrote:<br>
</div>
<blockquote
cite="mid:CANsrgPLdJzgqvv+vP9tP2tbKJ6rUCE6-Xbx5C7AwQVvR_aapdw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 9 January 2017 at 04:51, Ben
Gamari <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">Thomas Jakway <<a moz-do-not-send="true"
href="mailto:tjakway@nyu.edu">tjakway@nyu.edu</a>>
writes:<br>
<br>
> I want to be able to load certain GHC modules in
interpreted mode in<br>
> ghci so I can set breakpoints in them. I have
tests in the testsuite<br>
> that are compiled by inplace/bin/ghc-stage2 with
-package ghc. I can<br>
> load the tests with ghc-stage2 --interactive
-package ghc but since ghc<br>
> is compiled I can only set breakpoints in the tests
themselves. Loading<br>
> the relevant files by passing them as absolute
paths to :l loads them<br>
> but ghci doesn't stop at the breakpoints placed in
them (I'm guessing<br>
> because ghci doesn't realize that the module I just
loaded is meant to<br>
> replace the compiled version in -package ghc).<br>
><br>
> So if I use<br>
><br>
> inplace/bin/ghc-stage2 --interactive -package ghc
mytest.hs<br>
> then<br>
> :l abs/path/to/AsmCodeGen.hs<br>
><br>
> and set breakpoints, nothing happens.<br>
><br>
</span>Many of us would love to be able to load GHC into
GHCi. Unfortunately,<br>
we aren't currently in a position where this is possible.
The only thing<br>
standing in our way is the inability of GHC's interpreter
to run modules<br>
which use unboxed tuples. While there are a few modules
within GHC which<br>
use unboxed tuples, none of them are particularly
interesting for<br>
debugging purposes, so compiling them with -fobject-code
should be fine.<br>
In principle this could be accomplished by,<br>
<br>
{-# OPTIONS_GHC -fobject-code #-}<br>
<br>
However, as explained in #10965, GHC sadly does not allow
this. I spent<br>
a bit of time tonight trying to see if I could convince
GHC to first<br>
manually build object code for the needed modules, and
then load<br>
bytecode for the rest. Unfortunately recompilation
checking fought me at<br>
every turn.<br>
<br>
The current state of my attempt can be found here [1]. It
would be great<br>
if someone could pick it up. This will involve,<br>
<br>
* Working out how to convince the GHC to use the object
code for<br>
utils/Encoding.o instead of recompiling<br>
<br>
* Identifying all of the modules which can't be byte-code
compiled and<br>
add them to $obj_modules<br>
<br>
* Chassing down whatever other issues that might pop up
along the way<br>
<br>
I also wouldn't be surprised if you would need this GHC
patch [2].<br>
</blockquote>
<div><br>
</div>
<div>I would have thought that something like</div>
<div><br>
</div>
<div>:set -fobject-code</div>
<div>:load Main -- or whatever</div>
<div>-- modify some source file</div>
<div>:set -fbyte-code</div>
<div>:load Main</div>
<div><br>
</div>
<div>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...)</div>
<div><br>
</div>
<div>Cheers</div>
<div>Simon</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
<br>
[1] <a moz-do-not-send="true"
href="https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e"
rel="noreferrer" target="_blank">https://gist.github.com/<wbr>bgamari/<wbr>bd53e4fd6f3323599387ffc7b11d1a<wbr>1e</a><br>
[2] <a moz-do-not-send="true"
href="http://git.haskell.org/ghc.git/commit/326931db9cdc26f2d47657c1f084b9903fd46246"
rel="noreferrer" target="_blank">http://git.haskell.org/ghc.<wbr>git/commit/<wbr>326931db9cdc26f2d47657c1f084b9<wbr>903fd46246</a><br>
<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a moz-do-not-send="true"
href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a moz-do-not-send="true"
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>