[copy of the dropped reply, for anybody interested] 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 > * What does the generated DWARF information look like? So far we generate: - .debug_info: Information about all generated procedures and blocks. - .debug_line: Source-code links for all generated code - .debug_frame: Unwind information for the GHC stack - .debug_ghc: Everything we can't properly represent as DWARF > 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. > 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 > * 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). > 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. > * 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. Greetings, Peter Wortmann _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
