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

Johan Tibell johan.tibell at gmail.com
Fri Feb 28 10:45:18 UTC 2014

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

> >  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

> > 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.

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

More information about the ghc-devs mailing list