1. 15
  1. 10

    C is a compiled language, and you can’t just type in arbitrary C expressions in GDB and have them work.

    For comparison, LLDB uses clang to compile the expression, JIT it and then execute at the target. There are bugs and limitations, but generally you can do much more than just call a function (e.g. define a class, create an instance, call its method — all in a single expression!).

    It is much slower than the GDB’s interpreter-based approach though. For interactive use it’s often not really a problem (i.e. when typing an expression manually), but for IDE integration and custom visualizers, where you need to evaluate hundreds of expressions, it can be too slow. That’s the main reason I’ve implemented a custom C++ interpreter for LLDB — https://github.com/google/lldb-eval

    1. 1

      LLDB let’s you evaluate C++ too, which is impressive! Not sure whether GDB supports that.

      I use this a lot in debugging. When I create a complex class, like a B-tree node, I write a function called e.g. void dump(Node*) that writes a verbose representation of it to cerr. Then when I’m in the debugger I can say p dump(a_node) to see its contents.

      (I know that you can define custom formatters for LLDB, but I’ve never figured out how to create any nontrivial ones. Looks like you have to do it in Python, but I haven’t found clear docs on the introspection module. Links would be appreciated!)

    2. 4
      1. 1

        Great article! Worth mentioning is that you can also do breakpoint() in Python nowadays, although it will give you the regular Python debugger by default instead of an iPython session. This is configurable however: https://www.andreagrandi.it/2018/10/16/using-ipdb-with-python-37-breakpoint/