Richard Eisenberg <li...@richarde.dev> writes: > Thanks for this! > >> On Nov 17, 2021, at 7:27 AM, Moritz Angermann <moritz.angerm...@gmail.com> >> 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.html > 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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
