On Thu, Feb 27, 2014 at 6:43 PM, Peter Wortmann 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