Richard Eisenberg <li...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
