-prof GHC flag should not to be used with --ghc-options stack 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 stack, they should type:

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

It might not be clear that when stack 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, stack 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 cabal ticket: haskell/cabal#2827

[robstewart57]

To share this comment from the cabal ticket for the same report:

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.

[snoyberg]

Commit pushed to master which will error out early, thanks for the report!

[robstewart57]

Thank you. It isn't clear to me to what extent there will be a consistency between cabal and stack flags going forward, though in this case there is additional information about cabal's recent change in handling profile flags (see #2827):

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.

If I understand correctly, then cabal's handling of --enable-profiling for executables is to pass the -prof -fprof-auto-top to GHC and for libraries -prof -fprof-auto-exported is passed to GHC. This feels like a nice approach. IIRC the current stack exposure of profiling is with --library-profiling and separately with --executable-profiling. Does stack, or will stack in the future, automatically pass -fprof-auto-exported or -fprof-auto-top to GHC when these stack profiling flags are used?

[snoyberg]

Stack just uses Cabal for building under the surface, and passes
appropriate flags to the configure step. It should be doing exactly the
same thing as Cabal (you can run stack build -v to get more information).

On Thu, Sep 24, 2015 at 5:52 PM, Rob Stewart [email protected]
wrote:

Thank you. It isn't clear to me to what extent there will be a consistency
between cabal and stack flags going forward, though in this case there is
additional information about cabal's recent change in handling profile
flags (see #2827
haskell/cabal#2827 (comment)):

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.

If I understand correctly, then cabal's handling of --enable-profiling
for executables is to pass the -prof -fprof-auto-top to GHC and for
libraries -prof -fprof-auto-exported is passed to GHC. This feels like a
nice approach. IIRC the current stack exposure of profiling is with
--library-profiling and separately with --executable-profiling. Dose
stack, or will stack in the future, automatically pass
-fprof-auto-exported or -fprof-auto-top to GHC when these stack profiling
flags are used?

—
Reply to this email directly or view it on GitHub
#1015 (comment)
.

[flip111]

I use this command now to build stack build --ghc-options '-rtsopts -fprof-auto -fprof-auto-calls' --executable-profiling then i try to run stack exec vhdl -- +RTS -xc and i get this message:

vhdl: the flag -xc requires the program to be built with -prof
vhdl: 
vhdl: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args>
vhdl: 
vhdl:    +RTS    Indicates run time system options follow
vhdl:    -RTS    Indicates program arguments follow
vhdl:   --RTS    Indicates that ALL subsequent arguments will be given to the
vhdl:            program (including any of these RTS flags)
vhdl: 
vhdl: The following run time system options are available:
vhdl: 
vhdl:   -?       Prints this message and exits; the program is not executed
vhdl:   --info   Print information about the RTS used by this program
vhdl: 
vhdl:   -K<size>  Sets the maximum stack size (default: 80% of the heap)
vhdl:             Egs: -K32k -K512k -K8M
vhdl:   -ki<size> Sets the initial thread stack size (default 1k)  Egs: -ki4k -ki2m
vhdl:   -kc<size> Sets the stack chunk size (default 32k)
vhdl:   -kb<size> Sets the stack chunk buffer size (default 1k)
vhdl: 
vhdl:   -A<size> Sets the minimum allocation area size (default 512k) Egs: -A1m -A10k
vhdl:   -n<size> Allocation area chunk size (0 = disabled, default: 0)
vhdl:   -O<size> Sets the minimum size of the old generation (default 1M)
vhdl:   -M<size> Sets the maximum heap size (default unlimited)  Egs: -M256k -M1G
vhdl:   -H<size> Sets the minimum heap size (default 0M)   Egs: -H24m  -H1G
vhdl:   -m<n>    Minimum % of heap which must be available (default 3%)
vhdl:   -G<n>    Number of generations (default: 2)
vhdl:   -c<n>    Use in-place compaction instead of copying in the oldest generation
vhdl:            when live data is at least <n>% of the maximum heap size set with
vhdl:            -M (default: 30%)
vhdl:   -c       Use in-place compaction for all oldest generation collections
vhdl:            (the default is to use copying)
vhdl:   -w       Use mark-region for the oldest generation (experimental)
vhdl: 
vhdl:   -T         Collect GC statistics (useful for in-program statistics access)
vhdl:   -t[<file>] One-line GC statistics (if <file> omitted, uses stderr)
vhdl:   -s[<file>] Summary  GC statistics (if <file> omitted, uses stderr)
vhdl:   -S[<file>] Detailed GC statistics (if <file> omitted, uses stderr)
vhdl: 
vhdl: 
vhdl:   -Z       Don't squeeze out update frames on stack overflow
vhdl:   -B       Sound the bell at the start of each garbage collection
vhdl: 
vhdl:   -h       Heap residency profile (output file <program>.hp)
vhdl:   -i<sec>  Time between heap profile samples (seconds, default: 0.1)
vhdl: 
vhdl:   -C<secs>  Context-switch interval in seconds.
vhdl:             0 or no argument means switch as often as possible.
vhdl:             Default: 0.02 sec.
vhdl:   -V<secs>  Master tick interval in seconds (0 == disable timer).
vhdl:             This sets the resolution for -C and the heap profile timer -i,
vhdl:             and is the frequence of time profile samples.
vhdl:             Default: 0.01 sec.
vhdl: 
vhdl:   --install-signal-handlers=<yes|no>
vhdl:             Install signal handlers (default: yes)
vhdl:   -xm       Base address to mmap memory in the GHCi linker
vhdl:             (hex; must be <80000000)
vhdl:   -xq       The allocation limit given to a thread after it receives
vhdl:             an AllocationLimitExceeded exception. (default: 100k)
vhdl: 
vhdl: RTS options may also be specified using the GHCRTS environment variable.
vhdl: 
vhdl: Other RTS options may be available for programs compiled a different way.
vhdl: The GHC User's Guide has full details.
vhdl: 

Then when i add -prof i get the warning described in this issue. Is my run command wrong? Right now i'm in the "must build with -prof" <--> "can not use -prof use --executable-profiling instead" loop. I also tried this stack exec vhdl +RTS -xc and this stack +RTS -xc -- exec vhdl

[mgsloan]

@flip111 I don't have the link handy to the discussion, but this has been discussed before. You need to do it like this - stack exec -- vhdl +RTS -xc and not like this - stack exec vhdl -- +RTS -xc.

[flip111]

@mgsloan

» stack exec -- vhdl +RTS -xc
vhdl: the flag -xc requires the program to be built with -prof
... more lines ...

[flip111]

ok don't know what it was .. after a stack clean it no longer gave this message. Other users: be warned, and try stack clean !

[JonnyRa]

the actual flags are: --executable-profiling --library-profiling the enable prefix must be for an old version.