The available Linux debuggers are gdb and lldb. They both suck. They crash all the time, don’t understand the data types I care about, and they don’t make the data I need available at my fingertips as quickly as possible.
This feels like an overstatement. I use GDB with pwndbg quite often, in GUD mode for Emacs but now mostly over -i=dap, and it very rarely crashes for me. Not that I have no complaints, but I’ve written quite a few pretty printers for GDB, and I don’t understand how a debugger is supposed to magically “understand the data types I care about” without a similar manual effort from users. I have the impression the author just wanted a good debugger for Zig?
I don’t understand how a debugger is supposed to magically “understand the data types I care about” without a similar manual effort from users.
I think there’s a reasonable middle ground between “debugger doesn’t understand anything” and “debugger magically understands everything”. Namely, the debugger can:
have builtin support for all common/standard types, e.g. std::map.
have simple API for custom visualizers – I don’t find GDB and LLDB pretty printer APIs particularly easy to write. NatVis is IMO more user friendly (albeit being XML) and makes it much easier to iterate
have powerful API for custom visualizers, e.g. make it possible to write a visualizer that displays images, plays sounds, etc.
I just recorded a podcast with the author where we talked about the project: https://www.youtube.com/watch?v=stWBTv6grBc
This feels like an overstatement. I use GDB with pwndbg quite often, in GUD mode for Emacs but now mostly over -i=dap, and it very rarely crashes for me. Not that I have no complaints, but I’ve written quite a few pretty printers for GDB, and I don’t understand how a debugger is supposed to magically “understand the data types I care about” without a similar manual effort from users. I have the impression the author just wanted a good debugger for Zig?
Well, he said his motivation is debugging at work (chess.com) where they use C++ and Go.
I think there’s a reasonable middle ground between “debugger doesn’t understand anything” and “debugger magically understands everything”. Namely, the debugger can:
std::map.