As someone who started in the DOS/Windows world, both GDB and (especially) LLDB feel very awkward to use and those screenshots show a few good examples of why: in DEBUG/WinDbg/cdb the command to show the registers is simply 'r', and more than one register is shown on a line so you don't have to scroll up and down to read them all. No "0x" prefixes adding noise everywhere since the default is hex, nor extraneous '*' needed when setting breakpoints. A disassemble ('u') command that does what you expect instead of complaining (https://stackoverflow.com/questions/39016138/how-to-force-gd...). LLDB is even more verbose and perplexing. I could go on and on, but all these little things add up to make debugging with them extremely irritating. There's a classic quote about GDB being written to make you think twice about introducing bugs in your code, and I think whoever said that has a point...
I've always assumed that the `0x` prefix is to make copy & paste easier, i.e. so that you can copy the number, then immediate use it in a a C- or C++-like expression.
Personally, having started with gdb and recently having to use WinDbg a few times, I've had the opposite experience :P I think in the end some of the complaints you've mentioned may be valid, but most of it is overshadowed by simply getting used to using the tool, since they're all reasonably complicated to get a handle on.
I think WinDbg has a steeper learning curve; but needing to repeatedly and quickly type in the same (long) commands is not something that "getting used to" will ever overcome. All that happens is you get increasingly irritated and ask yourself "why couldn't they make it shorter" every time. Another example is showing the state of all threads:
There are other places where GDB shows its power, though.
Setting a conditional breakpoint: in WinDbg you have to express this as 'add breakpoint command that continues if the condition is false'. GDB makes it nice and simple. LLDB makes it unnecessarily verbose like it does with everything, but at least supports the concept:
WinDbg: bp foo ".if (poi(x) != 3) {gc}"
GDB: b foo if x == 3
LLDB: br add -n foo -c 'x == 3'
(WinDbg version based on the documentation; I might have messed it up.)
Calling a function: In both GDB and LLDB you can just call functions from the target using C syntax, including in the middle of a larger expression. In WinDbg you have to use multiple commands – .call followed by continuing – and it can't be embedded in an expression.
Well, except that sometimes calls just don't work in GDB/LLDB, particularly on embedded targets. I don't know why, but it's a major weakness…
Complex code evaluation: LLDB pulls out ahead of both GDB and WinDbg here, as it supports full C/C++ syntax, including things like loops, defining struct types, etc. This is pretty useful for things like automatically traversing a linked list, although it's not as powerful as it could be, e.g. you can't call debugger commands from the inside of an expression. GDB supports C/C++ expressions. WinDbg supposedly supports C++ expressions; I remember it as not working well, but that may be the fault of my inexperience.
Scripting: Both GDB and LLDB let you embed Python scripts inside the debugger, for custom commands, automation, etc. WinDbg has the third-party PyKd but I suspect it's less powerful.
Windbg version for conditional breakpoint should be: bp /w "x == 3" foo
Windbg also supports full c++ expressions and even linq style list comprehension with the "dx" command (instead of the old "??" command). You can even extend that with Natvis or JavaScript. Windbg has a script window built in to help you write extensions. You can do regular scripting stuff as well as extending the type system. For instance, if you have some special type that you want to provide a visualization of, you can write it in js and then whenever you look at the data with dx it'll use your js visualization.
I'd give some examples of what you can do in windbg with that but I'm on my phone. But someone wrote a js extension that could extend the built in type system to include types from an arbitrary c++ header... Or do things like a query for the largest function in a program with a single line of code.
Maybe the better word to have used there is "cumbersome"? The thought process seems to be "I am used to something that was designed for short commands and high information density at a terminal; having this perspective of knowing what is possible, gdb and lldb are both cumbersome... maybe people who haven't really experienced something better wouldn't realize that", which I think is totally fair.
