[ANNOUNCE] GHC 8.2.1 release candidate 1

[Boespflug, Mathieu]

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 <ben at well-typed.com> wrote:
> "Boespflug, Mathieu" <m at tweag.io> 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
>