GHCi doesn't work when built with way=p

[SamB]

I don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well...

naesten@hydrogen:~/hacking/haskell/ghc-hashedrepo% ./compiler/stage2/ghc-inplace_p --interactive    
GHCi, version 6.9.20080305: http://www.haskell.org/ghc/  :? for help
ghc_p-6.9.20080305: /home/naesten/hacking/haskell/ghc-hashedrepo/libraries/ghc-prim/dist/build/HSghc-prim-0.1.o: unknown symbol `traceCcszh_fast'
Loading package ghc-prim ... linking ... ghc_p-6.9.20080305: unable to load package `ghc-prim'

[SamB]

Btw, the symbol mentioned in the error is from something I'm working on... but the non_p ghci loads fine.

[simonmar]

GHCi + profiling doesn't work for deeper reasons than this: it would require a lot of work in the byte-code compiler and interpreter.

If you try 'ghci -prof' you get an error message, but in this case you built GHCi itself with -prof and tried to use it. I'll make it so that GHCi fails with a helpful error message earlier.

[SamB]

Replying to simonmar:

GHCi + profiling doesn't work for deeper reasons than this: it would require a lot of work in the byte-code compiler and interpreter.

Well, what about using -fobject-code then?

[simonmar]

Replying to SamB:

Well, what about using -fobject-code then?

Yes, that would make the problem smaller. However you may have noticed that -fobject-code doesn't currently apply to expressions typed at the prompt, so that would need to change. And you'd get no debugging support. And we'd need to modify Cabal to generate profiled GHCi libraries, as you pointed out earlier (and modify GHCi to load the profiled versions).

So it's possible, but not the work of an afternoon.

[simonmar]

See also #3285 - we should give a better error message when someone tries to use the GHC API in profiled mode.

[simonmar]

Fixed (as in, we get a good error message. GHCi still does not work when built profiled)

Wed Jul  1 05:23:54 PDT 2009  Simon Marlow <marlowsd@gmail.com>
  * Fix #2197 (properly this time)

[SamB]

Does this also work for Template Haskell? Even from Haddock?

What if I *want* GHCi to support profiling?

[simonmar]

Replying to SamB:

Does this also work for Template Haskell? Even from Haddock?

No, TH also doesn't work when GHC is built with -prof. I'll check what happens and make it emit an error message.

What if I *want* GHCi to support profiling?

There's a fair bit of work to do, and it's not clear it's worth the effort. The byte code compiler and interpreter have to be modified to support the different closure representations and other conventions of the profiling build.

[SamB]

Replying to simonmar:

Replying to SamB:

Does this also work for Template Haskell? Even from Haddock?

No, TH also doesn't work when GHC is built with -prof. I'll check what happens and make it emit an error message.

Yeah, that's what I meant. Hmm. And aren't there probably some other way to invoke the bytecode interpreter from the GHC API? It might be nice if all such ways would give the same exception...

What if I *want* GHCi to support profiling?

There's a fair bit of work to do, and it's not clear it's worth the effort. The byte code compiler and interpreter have to be modified to support the different closure representations and other conventions of the profiling build.

Hmm. I was expecting something more along the lines of "so make another ticket", which I've now done: see ticket #3360.