#11293: Compiler plugins don't work with profiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I suggest just tackling the profiling problem as a way of avoiding the "biting off more than you can chew" problem. While it's reasonable to try to anticipate things the cross-compiling version will need, I also suspect that you'll have to rewrite a lot of code anyway in the cross-compiling case. So if you anticipate too much, you'll find that you tied yourself up in knots for code that you didn't actually need. This is open source; as long as you're persistent, we can take the time to rewrite several times ;) Let's talk about the question of separate or together package databases. Common sense seems to dictate two contradictory positions: 1. Profiling versions of library "ought" to be in the same package database (or, at least, that's how we do it today) 2. Different cross-compiler targets "ought" to be in different package databases The crux of the matter is what having separate package databases buys you: you can have multiple copies of the package with the *same* IPID, but compiled differently. Sometimes this occurs in the single package database today (think about the profiling and non-profiling versions of a library), but these have to be awkwardly squeezed into the same package database entry. "Fortunately", the package database entry looks no different whether or not profiling libraries are present, so distros that want to bundle profiling libraries separately from the real ones just drop in some appropriately named p_hi and _p.a files. But it is also a pain for cabal- install Nix-style local builds, which doesn't really want to be retroactively stuffing profiling libraries into preexisting installations. So, *why* would you want to ensure that the profiling and non-profiling versions of a library get the same symbol names (via the IPID)? In a world where Template Haskell obeys strict staging, I think the answer is, never. But when we blur the lines between compile time and run time (as is encouraged by our current TH model, where there is no difference between a compile time and a runtime dependency), there are situations where you have a Name from the compile time world, and you want to lift (well, the type-class is called that but IMO it goes the wrong way!) a name from the compile-time world to the run-time world. And now the outrageous coincidence of compile-time and run-time entities (e.g., profiling and non-profiling) being named the same way is very useful, because you can just slide it from one realm to the next and still have it mean something. (Of course, if a preprocessor macro caused a Name to stop existing, then you did something bad and GHC will probably panic. So this kind of punning is not very safe--empirically, it seems to have been OK for profiling because no one ever CPPs for profiling.) So, if you are going to insist on a strict staging separation (I think, from GHC's perspective, everything can be implemented correctly this way; it's just a matter of user code not using NameG and Typeable in naughty ways), then I don't see any reason to have multiple package databases. If I build a profiling version of library, it should get its own entry in the package database, with a different IPID than its vanilla version (even if it's built with the same things), and its own set of dependencies (on the profiling versions of its deps.) And if the IPIDs are different, they can totally coexist in the same package database. Now you can eagerly error if a profiling library is not present (rather than wait for the attempt to load p_hi to fail). You can even eliminate the p_ prefix for profiling objects/interface files. Some "soft" advice on this patchset. I think it is wise to reduce churn when making a big patch like this. It makes the patch more likely to succeed. So I think there are two reasonable things you can do with this analysis: 1. You can start by refactoring profiling so that it lives in a separate database, eliminating p_hi files. This is a lot of churn: Cabal, build systems, distro packaging, etc. will all have to update--hopefully for the better. While you are doing this, you will run into the blocking problem of handling plugins and TH, since they are trying to load code from the profiling database which will no longer exist. So then you'll solve this ticket, by adding a second EPS/HPT, etc, as described above. 2. OR, you could just solve the blocking problem first, introducing a new EPS/HPT, but assuming everything is in the same database, and then solve that problem later (or not at all), perhaps when you need cross compiling to work. P.S. You wonder if you will need two databases. Let me flip around your question: rather than databases, does it every make sense to have more than two EPSes in GHC? The only situation is if GHC is compiling code for two targets *at the same time.* I can't think this would ever be relevant for cross-compilation, but rather mysteriously GHC does try to generate dynamic and non-dynamic objects at the same time using `-dynamic-too`. Still, we get along just fine with one EPS even in this case, so I think two is enough. Obviously you can maintain more databases on disk, but GHC will only ever look at two at a time. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11293#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler