Use -fobject-code in the GHCi script for loading GHC
ClosedPublic

Authored by mgsloan on Jul 27 2018, 7:14 PM.

Details

Summary

My very last commit to D4904 removed -fobject-code. I should have tested this
more thoroughly, because it is required to do a fresh ghci load, as some code
uses unboxed tuples.

One of my motivations for doing this was that if you run the script without
passing -odir / -hidir, it would pollute the source tree with .hi and .o files.
This also appeared to break subsequent builds. I've made it much less likely
that this will happen by instead specifying -odir and -hidir within the ghci
script rather than on the commandline.

I plan to open a separate diff which adds a test that these scripts work.

Until this patch is merged, the workaround is to do ./utils/ghc-in-ghci/run.sh -fobject-code

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
mgsloan created this revision.Jul 27 2018, 7:14 PM

Pinging @alpmestan / @bgamari . My bad for breaking the script with my last update (removal of -fobject-code). On the brightside, setting odir and hidir this way is much better.

mgsloan edited the summary of this revision. (Show Details)Jul 27 2018, 11:26 PM

Ah, indeed, it looks like when you run ghci without -fobject-code, but there are objects present from a prior run with -fobject-code, then it works. This is actually rather nice, because GHCi is much faster when generating bytecode instead of object code.

So, when I am using this I will probably use -fbyte-code until I run into the unboxed tuples thing, and do a reload with -fobject-code. Since most of the meat of GHC doesn't need object-code, it seems like often the bytecode interpreter can be used as long as the modules that do use unboxed tuples have been built to object code. Probably still good to have a default of -fobject-code for now so that it works out of the box.

I have opened https://ghc.haskell.org/trac/ghc/ticket/15454 proposing that GHCi automatically figures out the subset of modules that need to be built with object code, and volunteered to attempt implementation if y'all think it is a good idea and likely to be merged.

Nevermind, with many substantial changes to GHC's code, -fobject-code is needed to for it to load. So, this change should definitely be made to the scripts.

mgsloan updated this revision to Diff 17500.Jul 28 2018, 7:11 PM
  • Shorter name for ghc-in-ghci output dir
alpmestan accepted this revision.Jul 30 2018, 7:04 AM

LGTM. Yeah -fobject-code seems to be a better default. Just make sur you document the most efficient/handy (but more complicated) workflow somewhere visible like one of the "building ghc" pages on trac eventually, so that people can pick it up.

This revision is now accepted and ready to land.Jul 30 2018, 7:04 AM
monoidal accepted this revision.Aug 6 2018, 12:18 PM
This revision was automatically updated to reflect the committed changes.