4 ms·

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

by DSMan195276 5y ago

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.

userbinator 5y ago
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: GDB: i th LLDB: th i WinDbg: ~
- comex 5y ago
  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.
  - timbatron 5y ago
    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.

userbinator 5y ago

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: GDB: i th LLDB: th i WinDbg: ~

comex 5y ago
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.
- timbatron 5y ago
  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.