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 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 wrote:

...

Hi devs,

I was intrigued by Bodigrim's comment about HasCallStack in base ( https://github.com/haskell/core-libraries-committee/issues/5#issuecomment-97...) 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

Thanks for this!

On Nov 17, 2021, at 7:27 AM, Moritz Angermann wrote:

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.

This suggests to me that DWARF is the canonical format for debugging information on Linux and most BSDs. Is that statement correct? If so, how is that different to "platform-native"? Actually, the precise wording doesn't matter: I think I'm just requesting for a more direct relationship between "DWARF" and "compatibility with all the debugging and profiling tools you use for other languages".

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.

OK. So there is no macOS support here. That's fine -- I'm just trying to understand the status quo.

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

This implies that the DWARF work is (unsurprisingly) completely inapplicable for Windows.

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.

This suggests to me that the DWARF work is applicable to the macOS use case, but much more work still needs to be done. OK. Looking for more information, I checked the manual. And I found this: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/debug-info.ht... It's really helpful! And it suggests that I actually *can* do this on macOS. Perhaps that video will really happen after all. Forgive the noise -- I should have checked the manual first. :) Richard

Richard Eisenberg writes:

Thanks for this!

...

On Nov 17, 2021, at 7:27 AM, Moritz Angermann wrote:

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.

This suggests to me that DWARF is the canonical format for debugging information on Linux and most BSDs. Is that statement correct? If so, how is that different to "platform-native"? Actually, the precise wording doesn't matter: I think I'm just requesting for a more direct relationship between "DWARF" and "compatibility with all the debugging and profiling tools you use for other languages".

...

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.

OK. So there is no macOS support here. That's fine -- I'm just trying to understand the status quo.

...

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

This implies that the DWARF work is (unsurprisingly) completely inapplicable for Windows.

...

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.

This suggests to me that the DWARF work is applicable to the macOS use case, but much more work still needs to be done. OK.

Looking for more information, I checked the manual. And I found this: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/debug-info.ht... It's really helpful! And it suggests that I actually *can* do this on macOS. Perhaps that video will really happen after all.

I should clarify here that there are really two pieces to "debug information support": * the code generation logic responsible for producing the DWARF metadata * the RTS support for using that information to unwind the stack at runtime That section really describes the former. As noted in my earlier email and in #20702, the library used by the RTS to implement unwinding only targets ELF platforms. Cheers, - Ben

On Nov 18, 2021, at 10:29 AM, Ben Gamari wrote:

At this point, for backtrace support I would rather put my money is on a native Haskell stack unwinder (such as Sven Tennie's work [3,4]). Not only is it more portable but it is also more robust (whereas with DWARF any single object lacking debug information would break unwinding), and is significantly less costly since we know much more about the structure of our stack than a DWARF unwinder would.

Interesting -- this is helpful to know. I had heard about DWARF support for some years and thought that it would deliver stack traces. Now I will look for other sources. All good -- I understand how this is hard! -- and nice to know about. Thanks for the writeup, Ben. Richard

Another question would be where do I read about Haskell-native stack unwinder. The issue and MR Ben referenced have descriptions, but the MR didn't touch anything inside `docs` which is a bit scary. Are there any good recourses to dive into it besides the source code in the MR? -- Best, Artem On Thu, Nov 18, 2021, 11:31 AM Chris Smith wrote:

Just to satisfy my curiosity here, when talking about backtraces here, are you talking about a lexical call stack, or an execution stack?

On Thu, Nov 18, 2021 at 11:24 AM Richard Eisenberg wrote:

...

On Nov 18, 2021, at 10:29 AM, Ben Gamari wrote:

At this point, for backtrace support I would rather put my money is on a native Haskell stack unwinder (such as Sven Tennie's work [3,4]). Not only is it more portable but it is also more robust (whereas with DWARF any single object lacking debug information would break unwinding), and is significantly less costly since we know much more about the structure of our stack than a DWARF unwinder would.

Interesting -- this is helpful to know. I had heard about DWARF support for some years and thought that it would deliver stack traces. Now I will look for other sources. All good -- I understand how this is hard! -- and nice to know about.

Thanks for the writeup, Ben.

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

Am Fr., 19. Nov. 2021 um 01:09 Uhr schrieb Ben Gamari

:

Artem Pelenitsyn writes:

...

Another question would be where do I read about Haskell-native stack unwinder. The issue and MR Ben referenced have descriptions, but the MR didn't touch anything inside `docs` which is a bit scary. Are there any good recourses to dive into it besides the source code in the MR?

Indeed the user's guide documentation surrounding info table provenance should be updated to note this new capability.

Hey Ben, Hey Artem, Hey all, Thanks for bringing this up! I'll add some documentation to the user's guide and will likely write a blog post covering the "material" from notes in a more approachable way. Two details to note regarding the IPE based backtrace mechanism: - It's based on return frames on the STG stack. So, it doesn't work for trivial programs. A return frame is produced when the scrutinee of a case expression is evaluated. The test [1] shows a working example. - To get backtraces containing references in libraries, those have to be compiled with `-finfo-table-map`, too. Now that I've got the attention of many GHC-Devs: A big Thank-You! goes to Ben and Matthew that were always reachable and always very helpful during the whole development process of this feature! Best regards, Sven [1] - https://gitlab.haskell.org/ghc/ghc/-/blob/aed98ddaf72cc38fb570d8415cac5de9d8...