LLDB - kuotsanhsu/ccc GitHub Wiki

The choice of LLDB is arbitrary, one may very well use GDB. I use LLDB simply because it comes with my macbook, and I really like the vscode extension lldb-dap.

First and foremost, this article is an exploration of using the debugger for visualizing data structures, algorithms, and their interplay. Record-and-replay, snapshots, time travelling, hot reload, etc. are also of interest but will be pushed to the bottom of this article.

According to my experience, 3 classes of languages have the best debugging experience:

1. Languages that get compiled to native code: C, C++, D, Ada, Rust, Zig
   • The CPU and OS kernel is your debugger; CPU might as well be short for the "C processing unit". Arguably the best debugging support.
2. Well-defined interpreted languages: Java, Python, JavaScript, (Julia?)
   • Java: Intellij stop-the-world debugger.
   • Python: pdb with post-mortem debugging.
   • JavaScript: browsers and VSCode built-in.
   • Julia: never used it, but LLVM-JIT seems very interesting.
3. (Almost-purely) functional programming languages: Erlang/BEAM
   • Erlang/BEAM: the whole runtime is designed with debugging in mind.

.lldbinit

• LLDB Custom Commands
  • facebook/chisel

Variable Formatting

Data Formatters

Formatter Bytecode

To use custom data formatters, developers need to edit the global ~/.lldbinit file to make sure they are found and loaded. In addition to this rather manual workflow, developers or library authors can ship ship data formatters with their code in a format that allows LLDB automatically find them and run them securely.

Python Scripting

Scripting Bridge API

On Demand Symbols

Load only necessary debug symbols on demand.

This feature works by selectively enabling debug information for modules that the user focuses on. It is designed to be enabled and work without the user having to set any other settings and will try and determine when to enable debug info access from the modules automatically.

Since most users set breakpoints by file and line, this is an easy way for people to inform the debugger that they want focus on this module.

Symbolication

LLDB can be used to symbolicate your crash logs and can often provide more information than other symbolication programs:

1. Inlined functions
2. Variables that are in scope for an address, along with their locations

References

• hediet/vscode-debug-visualizer
• StackOverflow, Non blocking pyplot GUI for GDB python pretty printer
  • Analyzing C/C++ matrix in the gdb debugger with Python and Numpy
• What a good debugger can do
  • Breakpoints
    • LLDB Column Breakpoints
    • Conditional breakpoints
    • Tracing breakpoints (or tracepoints)
    • Data breakpoints
  • Data visualization
    • Visual Studio with Image Watch.
  • Expression evaluation
  • Concurrency and multithreading
    • How to debug deadlocks in Visual Studio
    • Freeze and unfreeze threads.
    • Visual Studio Parallel Stacks to visualize thread dependency and states.
  • Hot reload
  • Time travel
    • rr
    • Tomorrow Corporation Tech Demo
  • Omniscient debugging
    • Kyle Huey, Debugging by querying a database of all program state
    • Robert O'Callahan (author of rr), The State Of Debugging in 2022
    • Bil Lewis, Debugging Backwards in Time (2003)
    • Pernosco
    • WhiteBox
• https://github.com/vadimcn/codelldb/wiki/Custom-Data-Formatters
  • launch.json: lldb.launch.initCommands
  • python: __lldb_init_module(debugger, internal_dict)
• Source Level Debugging with LLVM
  • LLVM codeview for Windows PDB
    • llvm-readobj --codeview foo.obj
    • clang -g -gcodeview -S -emit-llvm foo.cpp
• How to Update Debug Info: A Guide for LLVM Pass Authors
• Libraries for Linux Tracepoints and user_events
• DPDK trace
  • Common trace format (CTF)

Ideas

• Change memory/registers live and branch.
• cling, llvm-repl
• dlopen, dlsym