"Boespflug, Mathieu"
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