Austin is dead right. In principle you could compile a plug-in with the exact same compiler (not just version but which build was used) as the one used to build stage-1. But that's delicate and we've never thought about it, so I doubt the other ancillary things Austin mentions would work.
Sorry Simon | -----Original Message----- | From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] | On Behalf Of Austin Seipp | Sent: 17 December 2012 23:26 | To: Daniel Vainsencher | Cc: Cvs-ghc@haskell.org | Subject: Re: Plugins, dynamic loading and GHCi | | We discussed this on IRC the other day but since I have a copy of GHC | open I dug through it to refresh my memory. I don't think it would be | currently possible with the way things currently are. Someone is free to | correct me. | | To explain the reasoning, I'll parrot that paragraph and specialize it | to this problem: When you build a stage1 compiler, that stage1 compiler | is built using symbols and components of the *host* compiler. | Let's say I build GHC HEAD stage1, with 7.6.1. So the stage1 compiler is | built by the *host* compiler. It links to the host compiler libraries | and runtime. Now, let's say we hypothetically compile a plugin for | stage1 (somehow.) But now we have a conundrum if we could even load it: | that stage1 plugin requires APIs from stage1 itself (for example, maybe | the definition of Core changed in HEAD, and your plugin depends on that) | but at runtime, when those object files are loaded into stage1, those | changed APIs are definitely not there, because | stage1 was built with the host, not with itself. So there is a link-time | mismatch. | | So, when stage2 is built, we are sure at runtime it is linked to the | same APIs that comprise the stage1 compiler. In this way, stage2 can | safely dynamically link packages it has built. This same line of | thinking extends to TH and GHCi: if you had a stage1 GHCi, bytecode | would be linked into it at runtime, but it would run against the host | compiler runtime, not the same runtime the bytecode was compiled for. | | You could theoretically do some loading-multiple-package-versioning | nonsense here, but considering there are plenty of non-versioned symbols | (especially C functions,) you're not going to get very far. | | And the bootstrapping issues aside, there are other direct aspects that | are organizational: DynamicLoading (which is used to grab the 'plugin' | declaration in a GHC plugin) depends directly on GHCi's Linker module, | since it has to link packages into the compiler dynamically anyway. | Obviously, Linker.lhs is only built during stage2, provided GHCi is | enabled, for all the prior reasons. So DynamicLoading must also depend | on #ifdef GHCI in this same way. | | I don't know how relevant dynamic-by-default here is, but I see how it's | going to get you around the first issue, which is the major one. | | On Mon, Dec 17, 2012 at 5:01 PM, Daniel Vainsencher | <daniel.vainsenc...@gmail.com> wrote: | > In SimplCore.lhs, addPlugin* is #ifdef GHCI. Is this dependency really | > necessary? plugins can be useful independently of the GHCi UI. | > | > From the wiki [1]: | > "Stage 1 does not support interactive execution (GHCi) and Template | > Haskell. The reason being that when running byte code we must | > dynamically link the packages, and only in stage 2 and later can we | > guarantee that the packages we dynamically link are compatible with | > those that GHC was built against (because they are the very same | packages). " | > This does not seem to be a reason to not support plugins and dynamic | > linking in general in stage though, or am I missing something? | > | > Besides finding the dependency in this direction a bit strange, | > building stage 2 to debug plugin mechanism problems is a bit slow. | > | > Thanks, | > Daniel Vainsencher | > | > _______________________________________________ | > Cvs-ghc mailing list | > Cvs-ghc@haskell.org | > http://www.haskell.org/mailman/listinfo/cvs-ghc | | | | -- | Regards, | Austin | | _______________________________________________ | Cvs-ghc mailing list | Cvs-ghc@haskell.org | http://www.haskell.org/mailman/listinfo/cvs-ghc _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
