You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
@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.
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).
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 >.
@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.
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, 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.
Activity
snoyberg commentedon Aug 30, 2015
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 commentedon Sep 1, 2015
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 commentedon Oct 3, 2015
I'll write up a brief explanation about using ghc options to profile.
gambogi commentedon Nov 2, 2015
Is this issue still open?
borsboom commentedon Nov 3, 2015
@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-autoand+RTS -xcto get rudimentary stack traces (without DWARF info), so that could potentially be improved.christiaanb commentedon Jul 25, 2016
Just wanted to leave a note as I wanted to use DWARF stack traces. Currently,
--ghc-options="-g"is not going to work becausestackstrips executables, and there is no way to turn off executable stripping (although the underlyingCaballibrary supports disabling executable stripping).mgsloan commentedon Jul 26, 2016
I'd be in favor of adding a
--dwarfflag which builds stuff with the debug symbols and skips stripping.1 remaining item
sjakobi commentedon Aug 12, 2016
I have added a note regarding DWARF support to the docs: 1c0d5ba
mgsloan commentedon Oct 4, 2016
Bumping to a P1 since I think this would be really handy. P1 status might get it more attention.
tibbe commentedon Oct 13, 2016
I found myself wanting this today. Turning off stripping would be a good start.
typedrat commentedon Oct 31, 2016
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 wordContents.On Mac:
dwarfdump $library-dirs[0]/$hs-libraries[0].dylib's output's fifth line must not be< EMPTY >.mgsloan commentedon Nov 8, 2016
@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 commentedon Nov 15, 2016
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 commentedon Nov 22, 2016
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 commentedon Nov 22, 2016
@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
DumpPackageright now, and it's just some sweeping up left at this point before I can submit a pull request to be reviewed.mgsloan commentedon Nov 27, 2016
This has been implemented by @SASinestro - good stuff!