-prof GHC flag should not to be used with --ghc-options cabal flag

[robstewart57]

When a user wants to run with cost modelling profiling enabled, they need to use +RTS -p. For this to work and when invoking GHC directly, the user types:

$ ghc -prof -fprof-auto -rtsopts Main.hs

However, if they are using cabal, they should type:

$ cabal install --enable-executable-profiling --enable-library-profiling --ghc-options="-fprof-auto -rtsopts"

It might not be clear that when cabal is used to invoke GHC, -prof should not be used in --ghc-options. If it is included, then they are likely to see compiler error messages relating to p_dyn, e.g.

Failed to load interface for ‘GHC.Integer.Type’
Perhaps you haven't installed the "p_dyn" libraries for package ‘integer-gmp-1.0.0.0’?
Use -v to see a list of the files searched for.

I initially raised this as a GHC documentation bug, but there it has been suggested that instead, cabal should throw an error or at least print a warning that -prof should not appear in the string passed to --ghc-options.

This is the GHC ticket, that I'd like to close once the corresponding stack and cabal tickets are discussed: https://ghc.haskell.org/trac/ghc/ticket/10894

This is the mirrored stack ticket: commercialhaskell/stack#1015

[ttuegel]

Actually, with the latest Cabal, they should probably only do

$ cabal install --enable-profiling --ghc-options="-fprof-auto -rtsopts"

and with the latest development version, they should only do

$ cabal install --enable-profiling --ghc-options="-rtsopts"

but these may be inadequately documented and it surely should be an error to include -prof in --ghc-options.

[robstewart57]

@ttuegel is that to say: that in the development version, when --enable-profiling is enabled then the -fprof-auto flag is automatically passed to GHC ?

[ttuegel]

@robstewart57 Well, not quite: we actually use -fprof-auto-exported for libraries and -fprof-auto-top for executables. In practice, -fprof-auto isn't usually what you want; it annotates everything, to the point that the cost of profiling begins to dominate the costs you are trying to profile. In case you really want -fprof-auto, it should be safe to add it to --ghc-options.

[ezyang]

I think Cabal strips out some --ghc-options currently? (Or this may be for things in the Cabal file). In that case, I'd suggest detecting -prof in the options and acting as if it was --enable-profiling.

[YPares]

But if you remove -prof from GHC options at building, how can you pass +RTS -p at execution?
It doesn't work, I tried it and the RTS complains.

[ttuegel]

@YPares Cabal gives -prof whenever you configure with --enable-profiling. @ezyang is suggesting that we forbid users from doing --ghc-options="-prof", which doesn't work right anyway.

[robstewart57]

@ttuegel And leading on from the mirrored stack github ticket about the same issue, stack commit commercialhaskell/stack@7f49966 now means that when the misuse of cabal-install that @ezyang is describing, i.e. --ghc-options="-prof" is passed to stack, the user now sees the following error message:

$ stack install --ghc-options="-prof"
When building with stack, you should not use the -prof GHC option
Instead, please use --enable-library-profiling and --enable-executable-profiling
See: https://github.com/commercialhaskell/stack/issues/1015
-prof GHC option submitted

[YPares]

Ok, indeed it does, but it's weird.
When I run "cabal run +RTS -p", I get:

cabal: the flag -p requires the program to be built with -prof
cabal: 
cabal: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args>
cabal:

But when I manually find the executable and run it ("./dist/build/my-exe/my-exe +RTS -p") then it works. I thought both were the same?

[ttuegel]

@YPares You are passing +RTS -p to cabal. You want to do cabal run -- +RTS -p instead.

[YPares]

@ttuegel Ok... now I feel stupid. Thanks a lot ^^. Is it possible to have cabal issue a warning when given +RTS options? Like "BEWARE. This is (maybe) not the RTS you are looking for"?

[Anton-Latukha]

Would add to this old thread.

I found this thread by:

cabal: the flag -hb requires the program to be built with -prof

and

Perhaps you haven't installed the "p_dyn" libraries for package ‘integer-gmp’?

I try to profile HNix inside nix-shell, using current v2-*options*, since those integrate with Nix.

I tried many variants:

1. Now using:

cabal v2-build --enable-tests --enable-profiling --ghc-options="-rtsopts" +RTS -p

I enabled profiling the right way, as you several times restated in this thread. But I get the same:

cabal: the flag -p requires the program to be built with -prof

But I already enabled profiling the right way.

2. And if I, as cabal asks, add -prof - I do the wrong thing, as you also restated above several times, and then I get the head topic of the thread:

/nix/store/3gahzbx1zk54wlnrnpw8wdbcbdrzxqhd-ghc-8.6.5/lib/ghc-8.6.5/template-hsc.h:91: note: this is the location of the previous definition
91 | #define hsc_alignment(x...)
|
Building library for terminal-size-0.3.2.1..
[1 of 3] Compiling System.Console.Terminal.Common ( src/System/Console/Terminal/Common.hs, dist/build/System/Console/Terminal/Common.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-unknown-linux):
lookupGlobal
Failed to load interface for ‘GHC.Integer.Type’
Perhaps you haven't installed the "p_dyn" libraries for package ‘integer-gmp’?
Use -v to see a list of the files searched for.
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/typecheck/TcEnv.hs:132:32 in ghc:TcEnv

Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

3. If I give +RTS -p not to cabal, but to executable - I got the same thing anyway.

hnix: the flag -p requires the program to be built with -prof

You, see - every variant that I was recommended to use, found or tried - results into the option configuration conflict. I am in the complete double bind.

[ttuegel]

I was reminded of this thread again today. We need to do two things:

1. Reject flags of the form -prof and -fprof* in the ghc-options field, to resolve the problem that was originally reported.
2. Disable (by default) user-specified RTS flags to cabal to clearly flag the problem that everyone trips over on their way to solve the first problem.

[Mikolaj]

This is a disaster. @ttuegel, you are completely right.

Dear @Anton-Latukha, @docteurklein, @kikofernandez, did you find a solution to your problem? If not, I'm here to help.

[OsePedro]

So what is the correct way to pass +RTS -p to an executable through Cabal 3.6.2, after building with cabal build --enable-profiling --ghc-options="-rtsopts"? I tried cabal run <Target> -- +RTS -p, but that triggered a complete rebuild of my library and executable, because Cabal thought the configuration had changed. Furthermore, the rebuilt binaries were not built with profiling, so the RTS refused to run my program with -p. I ended up rebuilding it again, with profiling, and running the executable directly with +RTS -p, instead of trying to figure out how to pass it those arguments through Cabal.

This may not be relevant, but I also passed --builddir=dist-profiling to both cabal build and cabal run.

[Mikolaj]

I'm not sure I'm reading this right

#7247 (comment)

but perhaps cabal run -- <Target> +RTS -p would work? If so, we need to decide what to do with it, fix, disable the misleading variants by default, document.

[hasufell]

One way to improve this would be to have cabal build write out the cli configuration to cabal.project.local, so a subsequent cabal run would pick it up.

However, that would be a breaking change and maybe more confusing?

[OsePedro]

@Mikolaj Oh, I didn't know you can pass the target after --. Unfortunately that doesn't solve the issue; it still triggers a complete rebuild without profiling.

[Mikolaj]

Unfortunately that doesn't solve the issue; it still triggers a complete rebuild without profiling.

Too bad. We really need to fix this.

One way to improve this would be to have cabal build write out the cli configuration to cabal.project.local, so a subsequent cabal run would pick it up.

Actually cabal configure is (re)designed to do such things and write to cabal.project.local (which is why cabal build should not write there IMHO). The idea is that instead of doing cabal build --hairy-options; cabal run --the-same-hairy-options-but-with-a-typo , you do cabal configure --hairy-options; cabal build; cabal run. Perhaps that's the right place to implement this?

[hasufell]

One way to improve this would be to have cabal build write out the cli configuration to cabal.project.local, so a subsequent cabal run would pick it up.

Actually cabal configure is (re)designed to do such things and write to cabal.project.local (which is why cabal build should not write there IMHO). The idea is that instead of doing cabal build --hairy-options; cabal run --the-same-hairy-options-but-with-a-typo , you do cabal configure --hairy-options; cabal build; cabal run. Perhaps that's the right place to implement this?

I'm aware, but as you can see... nobody is using cabal configure these days.

[arjunkathuria]

Ran into this, was using nix to run with --ghc-options passed and wanted to profile. It was rather unintuitive to figure out that this was the issue.

Maybe we show a warning or a helpful message that -prof should not be in --ghc-options until a permanent fix or possibly rejecting to accept it as a ghc-option lands?