Skip to content

Use the compiler that built ghc for dynamic code loading, for cross-compiling

In a non cross-compiled stage 2 compiler, this coincides with what we do today, because the stage 1 implementation of GHC is the same as the stage 2 implementation. But in a cross-compiler, these are NOT the same: the cross-compiler's ghc library handles the package database in the target platform, whereas the compiler that built stage 2 (stage 1)'s ghc library handles the package database for the compiler's platform.

So, the correct architecture for supporting compiler plugins is that GHC should use the package-database/interface infrastructure from the compiler which built it (stage 1) to handle loading.

A few things to note:

  1. There is not a backwards-compatibility problem, because we can assume that stage 1 and stage 2 are built from the same codebase. In particular, this does NOT mean that TH/plugins start working on a stage 1 compiler. You have to have bootstrapped from the same codebase.
  2. Plugins (and even Template Haskell) have to be a bit more careful to take advantage of this. We cannot just assume that the package database for plugins is the same as the package database for compiling (revisiting #11244 (closed)). Template Haskell is even trickier: we should NOT be allowed to use regular imports in splices; they have to go through TH_ONLY imports, c.f. #11377
  3. Can we actually link against the old version of ghc? Yes we can! All we need is (1) for it to have been built with a different IPID, and (2) to use module renaming to rename the relevant modules to a different module name, so that we can import them without a conflict.

Stepping back, there have been two approaches for dealing with the problem of Template Haskell/compiler plugins not reliably working:

  1. Run the code in an external process run in the target code, or
  2. Fix GHC to load code which is appropriately built for the bootstrap platform.

While (1) offers a more uniform environment for developers, (2) is absolutely necessary in some situations when you need to load code in the same address space as GHC, e.g. as mentioned in https://mail.haskell.org/pipermail/ghc-devs/2015-November/010478.html Thus, it seems worth pursuing both.

Trac metadata
Trac field Value
Version 7.11
Type FeatureRequest
TypeOfFailure OtherFailure
Priority lowest
Resolution Unresolved
Component Template Haskell
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information