How's the integration of DWARF support coming along?

[Ömer Sinan Ağacan]

Will generated stack traces be different that

---
Ömer Sinan Ağacan
http://osa1.net


2014-08-13 19:56 GMT+03:00 Johan Tibell <johan.tibell at gmail.com>:
> Yes, it doesn't use any code modification so it doesn't have runtime
> overhead (except when generating the actual trace) or interfere with
> compiler optimizations. In other words you can actually have it enabled at
> all time. It only requires that you compile with -g, just like with a C
> compiler.
>
>
> On Wed, Aug 13, 2014 at 6:45 PM, Ömer Sinan Ağacan <omeragacan at gmail.com>
> wrote:
>>
>> Is this stack trace support different than what we have currently?
>> (e.g. the one implemented with GHC.Stack and cost centers)
>>
>> ---
>> Ömer Sinan Ağacan
>> http://osa1.net
>>
>>
>> 2014-08-13 18:02 GMT+03:00 Johan Tibell <johan.tibell at gmail.com>:
>> > Hi,
>> >
>> > How's the integration of DWARF support coming along? It's probably one
>> > of
>> > the most important improvements to the runtime in quite some time since
>> > unlocks *two* important features, namely
>> >
>> >  * trustworthy profiling (using e.g. Linux perf events and other
>> > low-overhead, code preserving, sampling profilers), and
>> >  * stack traces.
>> >
>> > The former is really important to move our core libraries performance up
>> > a
>> > notch. Right now -prof is too invasive for it to be useful when
>> > evaluating
>> > the hotspots in these libraries (which are already often heavily tuned).
>> >
>> > The latter one is really important for real life Haskell on the server,
>> > where you can sometimes can get some crash that only happens once a day
>> > under very specific conditions. Knowing where the crash happens is then
>> > *very* useful.
>> >
>> > -- Johan
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>> >
>
>