DWARF support

[Carter Schonwald]

My understanding is that the platform specific part of ghc dwarf support
atm is the stack walking to generate dwarf data in stack traces. This is
because the dwarf stack walking Libs that are relatively mature are mostly
centered around elf?

It should still be possible with some work to use perf and gdb style tools,
though the complications are

a) you have to make sure all the Libs are built with dwarf

b) there’s some complications around loading / placing the dwarf files
adjacent to the object code files on Darwin (at least last time I checked
which was years ago following the wiki entry johan tibbel wrote up I
think?)

C) scheduler yields make gdb stepping through a program a tad more
annoying, I think the “setting the yield timer to zero” is the work around

D) the “source” you step through is essentially the c— z-encoded code? So
you still need to do some puzzling out of stuff


On Wed, Nov 17, 2021 at 7:28 AM Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> 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
>>
> _______________________________________________
> 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/b49a11e8/attachment.html>