Hi Ben, it sounds like some of the remaining limitations around DWARF support (e.g. finishing the stack sampling work, local bindings in GDB, ...) could make for a good Haskell Summer of Code project. Have you considered writing this up as one or two project ideas here: https://summer.haskell.org/ideas.html? As HSoC sponsors, we'd be more than happy to see someone pick this up.
Best, -- Mathieu Boespflug Founder at http://tweag.io. On 10 April 2017 at 22:52, Ben Gamari <[email protected]> wrote: > "Boespflug, Mathieu" <[email protected]> writes: > >> Hi Ben, >> >> thank you for this summary. The DWARF status page is helpful. Something was >> unclear to me though. There are three main potential use cases for DWARF >> that I see: >> >> 1. debugging, possibly with gdb >> 2. stack traces on exceptions >> 3. stack sampling, which is a form of performance profiling. >> >> Forgive me for these naive questions, but... Is (1) possible at all at this >> point? > > If you break into a program with gdb you will indeed get a usable > stacktrace. However, you cannot probe in-scope bindings as you can in > other languages. > >> If I compile GHC with all the right options as explained in the >> status page, do I magically get backtraces associated to all my >> exceptions? What should I do to get those? > > Ahh, thanks for pointing this out; this should be discussed on the > status page. I have a proposal allowing this here [1] and there is a > ticket here [2]. > > It turns out that this is actually a slightly tricky thing due to two > facts, > > * stack unwinding can be expensive > > * exceptions (especially asynchronous exceptions) are sometimes used > as a mechanism for normal control flow. > > Compatibility is quite tricky as under the current plan existing code > would drop callstack information if it catches and rethrows an > exception. I don't see any way to resolve this in a backwards > compatible manner. > >> It's my understanding that (3) is possible and works fine, even when >> FFI code is invoked, but slower than for C programs due to running >> user-level code to inspect the stack for each sample. Is that right? > > It's possible with my statistical profiling patches, but these are > currently not merged and the project is on hold due to lack of time. You > can, however, use perf. --callgraph will be broken in Haskell code, > however (e.g. you will only see the first stack frame). > > Cheers, > > - Ben > > [1] https://ghc.haskell.org/trac/ghc/wiki/Exceptions/StackTraces > [2] https://ghc.haskell.org/trac/ghc/ticket/12096 > _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
