<div dir="auto">Thanks Carter!</div><div dir="auto"><br></div><div dir="auto">Yes I completely forgot about the unwinding librarys. </div><div dir="auto"><br></div><div dir="auto">Sorry. My bad!</div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto"> Moritz</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed 17. Nov 2021 at 21:08, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">It should still be possible with some work to use perf and gdb style tools, though the complications are </div><div dir="auto"><br></div><div dir="auto">a) you have to make sure all the Libs are built with dwarf </div><div dir="auto"><br></div><div dir="auto">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?) </div><div dir="auto"><br></div><div dir="auto">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 </div><div dir="auto"><br></div><div dir="auto">D) the “source” you step through is essentially the c— z-encoded code? So you still need to do some puzzling out of stuff </div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 17, 2021 at 7:28 AM Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div dir="auto">Hi Richard,</div><div dir="auto"><br></div><div dir="auto">I’m not sure using platform native AND the term DWARF would help rather than add to confusion. Let me still try to</div><div>help a bit with context here.</div><div><br></div><div>For Linux and most BSDs, we have settled on the Executable and Linking Format (ELF) as the container format for</div><div>your machine code. And you might see where the inspiration for DWARF might come from.</div><div><br></div><div>For macOS, we have mach object (mach-o) as the container format. Its distinctly different to ELF, and also the</div><div>reason why Linux/BSD and macOS are sometimes substantially different, wrt to executable packaging and linking.</div><div><br></div><div>For windows we have Portable Executable (PE) as the container format.</div><div><br></div><div>My recollection is that we implemented DWARF in the NCG only for ELF. I've always wanted to scratch an itch</div><div>and try to make it work for mach-o as well, but never got around to it (yet?). The NCGs have flags that specify</div><div>if we want to emit debug info or not. I believe most codegens except for x86_64/elf ignore that flag.</div><div><br></div><div>This is a non-trivial engineering effort to get done properly, I believe. And we all spend time on many other things.</div><div><br>Depending on how familiar you are with development on macOS, you might know the notion of dSYM folders,</div><div>where macOS usually separate the application binary into the binary, and then stores the (d)ebug (SYM)bols in</div><div>a separate folder. Those are iirc DWARF objects in the end.</div><div><br></div><div>Hope this helps a bit; my recollection might be a bit rusty.</div><div><br></div><div>Best,</div><div> Moritz</div></div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed 17. Nov 2021 at 20:02, Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hi devs,<br>
<br>
I was intrigued by Bodigrim's comment about HasCallStack in base (<a href="https://github.com/haskell/core-libraries-committee/issues/5#issuecomment-970942580" rel="noreferrer" target="_blank">https://github.com/haskell/core-libraries-committee/issues/5#issuecomment-970942580</a>) 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.<br>
<br>
I found Ben's series of blog posts on DWARF, starting with <a href="https://www.haskell.org/ghc/blog/20200403-dwarf-1.html" rel="noreferrer" target="_blank">https://www.haskell.org/ghc/blog/20200403-dwarf-1.html</a>. 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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
Thanks!<br>
Richard<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>
</blockquote></div></div>