What does the DWARF information generated by your GHC branch look like?

[Johan Tibell]

On Thu, Feb 27, 2014 at 6:43 PM, Peter Wortmann <scpmw at leeds.ac.uk> wrote:

>
> Johan Tibell wrote:
> > I enjoyed reading your paper [1] and I have some questions.
>
> Thanks! The DWARF patches are currently under review for Trac #3693. Any
> feedback would be very appreciated:
> https://github.com/scpmw/ghc/commits/profiling-import


I haven't had time to look at it all. I added a comment on
https://github.com/scpmw/ghc/commit/bbf6f35d8c341c8aadca1a48657084c007837b21


> >  will you fill in the .debug_line section so that standard tools like
>  > "perf report" and gprof can be used on Haskell code?
>
> Yes, even though from a few quick tests the results of "perf report"
> aren't too useful, as source code links are pretty coarse and jump
> around a lot - especially for optimised Haskell code. There's the option
> to instead annotate with source code links to a generated ".dump-simpl"
> file, which might turn out to be more useful.
>

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.


> > Code pointers would be appreciated.
>
> Is this about how .debug_line information is generated? We take the same
> approach as LLVM (and GCC, I think) and simply annotate the assembly
> with suitable .file & .loc directives. That way we can leave all the
> heavy lifting to the assembler.
>
> Current patch is here:
> https://github.com/scpmw/ghc/commit/c5294576


Makes sense. Thanks.


> >  * Does your GHC allow DWARF information to be generated without
> > actually using any of the RTS (e.g. eventlog) machinery?
>
> The RTS just serves as a DWARF interpreter for its own executable (+
> libraries) in this, so yes, it's fully independent. On the other hand,
> having special code allows us to avoid a few subtleties about Haskell
> code that are hard to communicate to standard debugging tools
> (especially concerning stack tracing).
>

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.


> > Another way to ask the same question, do you have a ghc -g flag that
> > has no implication for the runtime settings?
>
> Right now -g does not affect the RTS at all. We might want to change
> that at some point though so we can get rid of the libdwarf dependency.
>

That sounds good (the don't affect the RTS part). I didn't understand the
libdwarf part.


> >  * Do you generate DW_TAG_subprogram sections in the .debug_info
> > section so that other tools can figure out the name of Haskell
> > functions?
>
> Yes, we are setting the "name" attribute to a suitable Haskell name.
> Sadly, at least GDB seems to ignore it and falls back to the symbol
> name. I investigated this some time ago, and I think the reason was that
> it doesn't recognize the Haskell language ID (which isn't standardized,
> obviously). Simply pretending to be C(++) might fix this, but I would be
> a bit scared of other side-effects.
>

Lets try to get our name standardized and pushed into GDB. It's hopefully
as simple as sending an email to the GDB devs.

Cheers,
Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/df226ddd/attachment.html>