Without question, Windows has the best debugging facilities. windbg is the best debugger, and when you have source code, visual studio's debugger is super nice. But guess what, windbg has so many commands that it's kind of hard to use for newbies and there's some great commands that even experts don't know about unless you go digging. This is many ways is like the bad UI in gdb. Over time, you learn.
Unfortunately, we're stuck with gdb, and improving it or making a new debugger requires massive effort and likely backing by one or more organizations (e.g. lldb has apple).
The ugliness of gdb won't change, but this presentation isn't about gdb's shortcomings -- it's about a "version" of gdb that supports reverse-debugging, which is really awesome.
I use undodb-gdb all the time and it's amazing. Consequently, I use gdb all the time. The result is that over time I've learned to deal with gdb's ugliness and so I get used to it. It's similar to complicated or hard-to-discover user interfaces in GUI programs.
> improving it or making a new debugger requires massive effort
Seeing what a single person (Greg Clayton) has done with his gui experiment for lldb (just run lldb and type "gui" command), I'm not sure the effort is so massive. Rather it's the fact that OSS developers have a really weak spot when it comes to design a good UI.
How so? I saw this suggested in some places but I found windbg atrociously complicated, even compared to plain GDB. It can debug the windows kernel, but that's about the best I can say about it. x64dbg and IDA's debugger were far nicer to work with for all desktop reverse engineering purposes.
In terms of non-RE debuggers, yeah, VS's is pretty good, but I don't find it that much better than anything else to say it's a must-have. Most source-level debuggers offer about the same feature set in only slightly different ways. It does the job and once you know one you pretty much know them all.
The UI is pretty bad but the commands are extremely powerful. It has commands and plugins to help you find deadlock, list out all system locks in a process, who owns them, layouts of data structures and lots more.
> "Unfortunately, we're stuck with gdb, and improving it or making a new debugger requires massive effort and likely backing by one or more organizations (e.g. lldb has apple)."
Being stuck with gdb doesn't mean you can't do those things in IDEs though. Visual Studio has a gdb front end so you can run gdb on the target and debug in Visual Studio.
Unfortunately, we're stuck with gdb, and improving it or making a new debugger requires massive effort and likely backing by one or more organizations (e.g. lldb has apple).
The ugliness of gdb won't change, but this presentation isn't about gdb's shortcomings -- it's about a "version" of gdb that supports reverse-debugging, which is really awesome.
I use undodb-gdb all the time and it's amazing. Consequently, I use gdb all the time. The result is that over time I've learned to deal with gdb's ugliness and so I get used to it. It's similar to complicated or hard-to-discover user interfaces in GUI programs.