How's the integration of DWARF support coming along?

[Johan Tibell]

Seeing the code on Phab it two weeks sounds great.

Do you mind expanding on what tick scopes are. It sounds scarily like
something that happens at runtime. :)


On Wed, Aug 13, 2014 at 8:49 PM, Peter Wortmann <scpmw at leeds.ac.uk> wrote:

>
>
> At this point I have a bit more time on my hands again (modulo post-thesis
> vacations), but we are basically still in “review hell”.
>
> I think “just” for perf_events support we’d need the following patches[1]:
> 1. Source notes (Core support)
> 2. Source notes (CorePrep & Stg support)
> 3. Source notes (Cmm support)
> 4. Tick scopes
> 5. Debug data extraction (NCG support)
> 6. Generate .loc/.file directives
>
> We have a basic “okay” from the Simons up to number 2 (conditional on
> better documentation). Number 4 sticks out because Simon Marlow wanted to
> have a closer look at it - this is basically about how to maintain source
> ticks in a robust fashion on the Cmm level (see also section 5.5 of my
> thesis[2]).
>
> Meanwhile I have ported NCG DWARF generation over to Mac Os, and am
> working on reviving LLVM support. My plan was to check that I didn’t
> accidentally break Linux support, then push for review again in a week or
> so (Phab?).
>
> Greetings,
>   Peter
>
> [1] https://github.com/scpmw/ghc/commits/profiling-import
> [2] http://www.personal.leeds.ac.uk/~scpmw/static/thesis.pdf
>
> On 13 Aug 2014, at 20:01, Johan Tibell <johan.tibell at gmail.com<mailto:
> johan.tibell at gmail.com>> wrote:
>
> What's the minimal amount of work we need to do to just get the dwarf data
> in the codegen by 7.10 (RC late december) so we can start using e.g. linux
> perf events to profile Haskell programs?
>
>
> On Wed, Aug 13, 2014 at 7:31 PM, Arash Rouhani <rarash at student.chalmers.se
> <mailto:rarash at student.chalmers.se>> wrote:
> Hi Johan!
>
> 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 [1], it should answer Ömer's question of how
> we retrieve a stack from a language you think won't have a stack. :)
>
> Cheers,
> Arash
>
> [1]: http://arashrouhani.com/papers/master-thesis.pdf
>
>
>
>
>
> On 2014-08-13 17:02, Johan Tibell wrote:
> 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<mailto:ghc-devs at haskell.org>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140813/379d4d90/attachment.html>