How's the integration of DWARF support coming along?
rarash at student.chalmers.se
Wed Aug 13 17:31:58 UTC 2014
I haven't done much (just been lazy) lately, I've tried to benchmark my
results but I don't get any sensible results at all yet.
Last time Peter said he's working on a more portable way to read dwarf
information that doesn't require Linux. But I'm sure he'll give a more
acurate update than me soon in this mail thread.
As for stack traces, I don't think there's any big tasks left, but I
summarize what I have in mind:
* The haskell interface is done and I've iterated on it a bit, so it's
in a decent shape at least. Some parts still need testing.
* I wish I could implement the `forceCaseContinuation` that I've
described in my thesis. If someone is good with code generation (I
just suck at it, it's probably simple) and is willing to assist me a
bit, please say so. :)
* I tried benchmarking, I gave up after not getting any useful results.
* I'm unfortunately totally incapable to help out with dwarf debug
data generation, only Peter knows that part, particularly I never
grasped his theoretical framework of causality in Haskell.
* Peter and I have finally agreed on a simple and sensible way to
implement `catchWithStack` that have all most good properties you
would like. I just need to implement it and test it. I can
definitely man up and implement this. :)
Here's my master thesis btw , it should answer Ömer's question of how
we retrieve a stack from a language you think won't have a stack. :)
On 2014-08-13 17:02, Johan Tibell wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs