DWARF support

[Moritz Angermann]

Thanks Carter!

Yes I completely forgot about the unwinding librarys.

Sorry. My bad!

Best,
 Moritz

On Wed 17. Nov 2021 at 21:08, Carter Schonwald <carter.schonwald at gmail.com>
wrote:

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