<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 27, 2014 at 6:43 PM, Peter Wortmann <span dir="ltr"><<a href="mailto:scpmw@leeds.ac.uk" target="_blank">scpmw@leeds.ac.uk</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>
Johan Tibell wrote:<br>
> I enjoyed reading your paper [1] and I have some questions.<br>
<br>
</div>Thanks! The DWARF patches are currently under review for Trac #3693. Any<br>
feedback would be very appreciated:<br>
<a href="https://github.com/scpmw/ghc/commits/profiling-import" target="_blank">https://github.com/scpmw/ghc/commits/profiling-import</a></blockquote><div><br></div><div>I haven't had time to look at it all. I added a comment on <a href="https://github.com/scpmw/ghc/commit/bbf6f35d8c341c8aadca1a48657084c007837b21">https://github.com/scpmw/ghc/commit/bbf6f35d8c341c8aadca1a48657084c007837b21</a></div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">>  will you fill in the .debug_line section so that standard tools like<br>

</div><div class="">
> "perf report" and gprof can be used on Haskell code?<br>
<br>
</div>Yes, even though from a few quick tests the results of "perf report"<br>
aren't too useful, as source code links are pretty coarse and jump<br>
around a lot - especially for optimised Haskell code. There's the option<br>
to instead annotate with source code links to a generated ".dump-simpl"<br>
file, which might turn out to be more useful.<br></blockquote><div><br></div><div>I think that in general we should be as "standard" (i.e. close to how e.g. GCC uses DWARF) as possible and put extra information in e.g. .debug_ghc. That way we maximize the chance that standard tools will do something sensible.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">> Code pointers would be appreciated.<br>
<br>
</div>Is this about how .debug_line information is generated? We take the same<br>
approach as LLVM (and GCC, I think) and simply annotate the assembly<br>
with suitable .file & .loc directives. That way we can leave all the<br>
heavy lifting to the assembler.<br>
<br>
Current patch is here:<br>
<a href="https://github.com/scpmw/ghc/commit/c5294576" target="_blank">https://github.com/scpmw/ghc/commit/c5294576</a></blockquote><div><br></div><div>Makes sense. Thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="">>  * Does your GHC allow DWARF information to be generated without<br>
> actually using any of the RTS (e.g. eventlog) machinery?<br>
<br>
</div>The RTS just serves as a DWARF interpreter for its own executable (+<br>
libraries) in this, so yes, it's fully independent. On the other hand,<br>
having special code allows us to avoid a few subtleties about Haskell<br>
code that are hard to communicate to standard debugging tools<br>
(especially concerning stack tracing).<br></blockquote><div><br></div><div>Sounds good. As long as it's possible to use this without the RTS/eventlog support I be happy. I have profiling needs (e.g. in unordered-containers) were changes in the <5% are interesting and any extra overhead will skew the results.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">> Another way to ask the same question, do you have a ghc -g flag that<br>
> has no implication for the runtime settings?<br>
<br>
</div>Right now -g does not affect the RTS at all. We might want to change<br>
that at some point though so we can get rid of the libdwarf dependency.<br></blockquote><div><br></div><div>That sounds good (the don't affect the RTS part). I didn't understand the libdwarf part.</div><div> </div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">>  * Do you generate DW_TAG_subprogram sections in the .debug_info<br>
> section so that other tools can figure out the name of Haskell<br>
> functions?<br>
<br>
</div>Yes, we are setting the "name" attribute to a suitable Haskell name.<br>
Sadly, at least GDB seems to ignore it and falls back to the symbol<br>
name. I investigated this some time ago, and I think the reason was that<br>
it doesn't recognize the Haskell language ID (which isn't standardized,<br>
obviously). Simply pretending to be C(++) might fix this, but I would be<br>
a bit scared of other side-effects.<br></blockquote><div><br></div><div>Lets try to get our name standardized and pushed into GDB. It's hopefully as simple as sending an email to the GDB devs.</div><div><br></div><div>

Cheers,</div><div>Johan</div><div> </div></div></div></div>