DWARF support

[Ben Gamari]

Richard Eisenberg <lists at richarde.dev> writes:

> Hi devs,
>
> I was intrigued by Bodigrim's comment about HasCallStack in base
> (https://github.com/haskell/core-libraries-committee/issues/5#issuecomment-970942580)
> that there are other alternatives, such as DWARF. Over the years, I
> had tuned out every time I saw the word DWARF: it was (and is!) an
> unknown acronym and seems like a low-level detail. But Bodigrim's
> comment made me want to re-think this stance.
>
> I found Ben's series of blog posts on DWARF, starting with
> https://www.haskell.org/ghc/blog/20200403-dwarf-1.html. These are very
> helpful! In particular, they taught me that DWARF = platform-native
> debugging metadata. Is that translation accurate? If so, perhaps we
> should use both names: if I see that GHC x.y.z has DWARF support, I
> quickly scroll to the next bullet. If I see that GHC x.y.z has support
> for platform-native debugging metadata and is now compatible with e.g.
> gdb, I'm interested.
>
> Going further, I have a key question for my use case: is this support
> available on Mac? The first post in the series describes support for
> "Linux and several BSDs" and the last post says that "Windows PDB
> support" is future work. (Is "PDB" platform-native debugging metadata
> for Windows? I don't know.) But I don't see any mention of Mac. What's
> the status here?
>
The problem is that DWARF is only one format for debugging information.
Windows uses PDB, which is practically undocumented and consequently
essentially unsupportable, AFAICT. I believe some other platforms still
use the STABS format, which I do not believe we will ever support.

Sadly, Darwin is, as usual, a bit of a tricky case. The platform seems
to use a variant of the typical "split-debug" packaging configuration
for debug information. Apple calls this separate debug information
`dsym` files. In typical Apple fasion, the documentation surrounding
this mechanism is very poor. It appears that the user or packager must
generate these files manually using dsymutils but it's quite unclear how
a consuming library is to find the dsym for a particular object.
To make matters worse, the library that we use for unwinding, libdw, has
absolutely no support for it.

Ultimately, my goals for working on DWARF were:

 1. To ensure that we had *some* baseline symbol and line information
    support on platforms for low-level debugging. I have found even
    basic line information invaluable when looking at code generation
    issues and thankfully gdb can always use inline DWARF information,
    even on platforms like on Windows where it isn't quite "native"

 2. Providing an interface for users to unwind the stack from Haskell on
    the "easy" platforms (e.g. the ELF-based BSDs and Linux). I was
    hoping someone would express interest in picking up Darwin and
    Windows, at which point we could start to push this as a universal
    backtrace mechanism, but sadly this hasn't yet happened.

 3. Provide a basis for statistic profiling support. This is sadly
    complicated by the stack pointer issues that Andreas and I note in
    our respective blog posts [1,2]. Sadly, overcoming this without
    breaking potential users is harder than we thought due to
    limitations in LLVM.

At this point, for backtrace support I would rather put my money is on a
native Haskell stack unwinder (such as Sven Tennie's work [3,4]). Not only
is it more portable but it is also more robust (whereas with DWARF any
single object lacking debug information would break unwinding), and is
significantly less costly since we know much more about the structure of
our stack than a DWARF unwinder would.

Cheers,

- Ben


[1] https://well-typed.com/blog/2020/04/dwarf-4/
[2] https://well-typed.com/blog/2021/07/ghc-sp-profiling/
[3] https://gitlab.haskell.org/ghc/ghc/-/issues/18163
[4] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5456
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20211118/b10e1b16/attachment.sig>