Add a --dwarf flag for DWARF debugging

[radix]

Say I wanted to build my project with all the debugging options, including stuff like DWARF data. The page about DWARF support in GHC says that you have to pass -g to ghc to get it to generate these symbols, but what about all the packages I depend on, and the RTS itself? ("you will need to compile both libraries and the runtime system with debugging support (GhcRtsHcOpts += -g and GhcLibHcOpts += -g).") I guess to make it easy to have a GHC RTS with debugging we'd need bindists that have symbols in them -- I'm not sure if the default 7.10.2 ones have them.

Likewise all this stuff for GHC's profiling options. Is there a way to easily just turn on all profiling options for a project and rebuild everything so I can profile everything?

Maybe this is already pretty easy and this should just be resolved with some documentation in the guide.

[snoyberg]

master has support for setting arbitrary ghc-options in your stack.yaml file:

https://github.com/commercialhaskell/stack/wiki/stack.yaml#ghc-options

I can't speak to the settings used by the official bindists, however.

[radix]

Thanks for the note. I think it'd be nice to mention this specifically with respect to "debugging" and/or "profiling" in the Guide. (I specifically just did a search for the words "profile" or "debug" in the guide and didn't find one). I'd try to put together a PR (as evinced by the time it took to respond to you on this ticket) I am lacking time.

[GregorySchwartz]

I'll write up a brief explanation about using ghc options to profile.

[gambogi]

Is this issue still open?

[borsboom]

@gambogi The documentation that @GregorySchwartz wrote doesn't address the DWARF case. I'm guessing it's too early in development for Stack to really support that case well anyway, but I haven't done any research into it (e.g. whether GHC 7.10.2 bindists include DWARF debugging info -- I'm assuming they don't). The profiling docs that @GregorySchwartz added look good but also don't cover using -fprof-auto and +RTS -xc to get rudimentary stack traces (without DWARF info), so that could potentially be improved.

[christiaanb]

Just wanted to leave a note as I wanted to use DWARF stack traces. Currently, --ghc-options="-g" is not going to work because stack strips executables, and there is no way to turn off executable stripping (although the underlying Cabal library supports disabling executable stripping).

[mgsloan]

I'd be in favor of adding a --dwarf flag which builds stuff with the debug symbols and skips stripping.

[sjakobi]

I have added a note regarding DWARF support to the docs: 1c0d5ba

[mgsloan]

Bumping to a P1 since I think this would be really handy. P1 status might get it more attention.

[tibbe]

I found myself wanting this today. Turning off stripping would be a good start.

[typedrat]

I've started working on this starting at typedrat/stack@f0c9865 a little. I've got something resembling configuration options for it and the actual change itself done, but I'm stuck on how to track what is and isn't built stripped, because GHC unfortunately doesn't seem to track that at first glance. I'm not immediately comfortable doing something hacky with shelling out (not to mention the whole "doing IO" issue) because it would be different for OS X and Linux (and I can't figure out how to do it on Linux without getting -way- too fuzzy/brittle with my heuristics) and would be completely vestigial on Windows, either. I'll keep working using aforementioned brittle heuristic unless anyone has a better idea, since I need this even if my changes don't get merged.

For my own reference as much as anything, the heuristics in psuedoshell:
On Linux: readelf --debug-dump=info --dwarf-depth=1 $library-dirs[0]/$hs-libraries[0].a's output's third line must start with the word Contents.
On Mac: dwarfdump $library-dirs[0]/$hs-libraries[0].dylib's output's fifth line must not be < EMPTY >.

    hasDebuggingSymbols :: DumpPackage Bool Bool -> IO Bool
    hasDebuggingSymbols DumpPackage{..} = case buildOS of
        Windows -> False -- No support, so it can't be there.
        OSX -> liftM ((/= "< EMPTY >") . (!! 4) . lines) $
            readProcess "dwarfdump" [libDir </> libName ++ ".dylib"] ""
        Linux -> liftM ((== "Contents") . head . words . (!! 2) . lines) $
            readProcess "readelf" ["--debug-dump=info", "--dwarf-depth=1", libDir </> libName ++ ".a"] ""
        where
            libDir  = head dpLibDirs
            libName = T.unpack . head $ dpLibraries 

[mgsloan]

@SASinestro Thanks for working on this! I'm not sure what to do about keeping track of library stripping. We could possibly store some extra metadata with the installed packages.

[typedrat]

Unfortunately, I don't feel comfortable making a decision about how to handle metadata storage (which is what would be required, that or Cabal-style "wipe out everything and rebuild with the global flag set", which isn't an option as far as I'm concerned) myself. Except for that, it's done, though.

[borsboom]

This reminds me the most of where we're keeping track of libraries that have been built with profiling and/or haddocks, so maybe something similar?

[typedrat]

@borsboom, I was being rather dumb and didn't think about the fact that there's already a place things like this are done. I'm adding it onto DumpPackage right now, and it's just some sweeping up left at this point before I can submit a pull request to be reviewed.

[mgsloan]

This has been implemented by @SASinestro - good stuff!