DWARF support

[Moritz Angermann]

Hi Richard,

I’m not sure using platform native AND  the term DWARF would help rather
than add to confusion.  Let me still try to
help a bit with context here.

For Linux and most BSDs, we have settled on the Executable and Linking
Format (ELF) as the container format for
your machine code.  And you might see where the inspiration for DWARF
might come from.

For macOS, we have mach object (mach-o) as the container format. Its
distinctly different to ELF, and also the
reason why Linux/BSD and macOS are sometimes substantially different, wrt
to executable packaging and linking.

For windows we have Portable Executable (PE) as the container format.

My recollection is that we implemented DWARF in the NCG only for ELF.  I've
always wanted to scratch an itch
and try to make it work for mach-o as well, but never got around to it
(yet?).  The NCGs have flags that specify
if we want to emit debug info or not.  I believe most codegens except for
x86_64/elf ignore that flag.

This is a non-trivial engineering effort to get done properly, I believe.
And we all spend time on many other things.

Depending on how familiar you are with development on macOS, you might know
the notion of dSYM folders,
where macOS usually separate the application binary into the binary, and
then stores the (d)ebug (SYM)bols in
a separate folder. Those are iirc DWARF objects in the end.

Hope this helps a bit; my recollection might be a bit rusty.

Best,
 Moritz



On Wed 17. Nov 2021 at 20:02, Richard Eisenberg <lists at richarde.dev> wrote:

> 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?
>
> It would be very cool if this conversation ends with me making a video on
> how a few simple GHC flags can allow us to, say, get a stack trace on a
> pattern-match failure in a Haskell program.
>
> Thanks!
> Richard
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20211117/7e98cf5a/attachment.html>