6 ms·

Improving GDB register model compatibility in LLDB

49 points by fcambus 5y ago

jes 5y ago
How well supported is lldb (1) from within GNU Emacs on macOS?
userbinator 5y ago
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-gdb-to-disassemble-code-when-it-says-no-function-contains-program 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...
- lanza 5y ago
  Being unfamiliar with a tool doesn't make it awkward.
  - saurik 5y ago
    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.
    - amelius 5y ago
      Aren't these tools designed such that others can build a GUI on top of them?
- 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.
- k4st 5y ago
  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.

49 points by fcambus 5y ago

jes 5y ago

How well supported is lldb (1) from within GNU Emacs on macOS?

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-gdb-to-disassemble-code-when-it-says-no-function-contains-program 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...

lanza 5y ago
Being unfamiliar with a tool doesn't make it awkward.
- saurik 5y ago
  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.
  - amelius 5y ago
    Aren't these tools designed such that others can build a GUI on top of them?
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.
k4st 5y ago
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.