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.schonw...@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.angerm...@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 <li...@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@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
