How's the integration of DWARF support coming along?
Ömer Sinan Ağacan
omeragacan at gmail.com
Wed Aug 13 17:08:07 UTC 2014
Will generated stack traces be different that
Ömer Sinan Ağacan
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
> On Wed, Aug 13, 2014 at 6:45 PM, Ömer Sinan Ağacan <omeragacan at gmail.com>
>> 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
>> 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
More information about the ghc-devs