New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a `--dwarf` flag for DWARF debugging #877

Closed
radix opened this Issue Aug 29, 2015 · 16 comments

Comments

Projects
None yet
10 participants
@radix
Contributor

radix commented Aug 29, 2015

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

This comment has been minimized.

Contributor

snoyberg commented 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.

@snoyberg snoyberg added this to the Support milestone Aug 30, 2015

@radix

This comment has been minimized.

Contributor

radix commented 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

This comment has been minimized.

Contributor

GregorySchwartz commented Oct 3, 2015

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

@gambogi

This comment has been minimized.

Contributor

gambogi commented Nov 2, 2015

Is this issue still open?

@borsboom

This comment has been minimized.

Contributor

borsboom commented 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-auto and +RTS -xc to get rudimentary stack traces (without DWARF info), so that could potentially be improved.

@christiaanb

This comment has been minimized.

christiaanb commented 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 because stack strips executables, and there is no way to turn off executable stripping (although the underlying Cabal library supports disabling executable stripping).

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Jul 26, 2016

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

@sjakobi sjakobi changed the title from Can stack enable debugging/profiling? to Add a `--dwarf` flag for DWARF debugging Aug 12, 2016

@sjakobi

This comment has been minimized.

Contributor

sjakobi commented Aug 12, 2016

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

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Oct 4, 2016

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

@mgsloan mgsloan modified the milestones: P1: Must, P2: Should Oct 4, 2016

@tibbe

This comment has been minimized.

tibbe commented Oct 13, 2016

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

@typedrat

This comment has been minimized.

Contributor

typedrat commented 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 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

This comment has been minimized.

Collaborator

mgsloan commented 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

This comment has been minimized.

Contributor

typedrat commented 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

This comment has been minimized.

Contributor

borsboom commented 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

This comment has been minimized.

Contributor

typedrat commented 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 DumpPackage right now, and it's just some sweeping up left at this point before I can submit a pull request to be reviewed.

@typedrat typedrat referenced this issue Nov 22, 2016

Merged

DWARF debugging support #2801

2 of 2 tasks complete
@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Nov 27, 2016

This has been implemented by @SASinestro - good stuff!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment