clang安装后需加-g且禁用优化才能配合lldb调试；-o2/o3会导致变量不可见、断点失效，推荐clang -g -o0编译，并验证dwarf信息与路径映射。

Clang 安装后不能直接“配合”LLDB 调试——必须确保编译时生成调试信息，且 LLDB 能正确加载符号，否则断点不命中、变量显示为 (void)、bt 回溯为空，都是常见后果。

编译必须加 -g，且慎用优化

Clang 默认不嵌入调试信息，-g 是硬性前提；而 -O2 或 -O3 会导致变量被寄存器优化掉、行号错乱、内联函数无法设断点：

• clang -g -O0 -o app main.c —— 最稳妥的调试编译（-O0 关闭优化）
• clang -g -O1 -o app main.c —— 可接受，但局部变量可能偶尔不可见
• clang -g -O2 main.c —— 不推荐：fr v 看不到变量，step 可能跳过整段逻辑
• 验证是否生效：readelf -wi app | head -5 应输出 DW_TAG_compile_unit 等 DWARF 条目

lldb 启动和断点设置要匹配源码位置

LLDB 不会自动猜你改了哪行代码。如果源文件路径变了（比如从 /home/user/proj/main.c 移到 /tmp/main.c），断点会失效或提示 no debug info：

Clang 22.1.3

Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。

下载

• 启动方式优先用：lldb ./app（而非 lldb 进去再 file app），避免路径解析偏差
• 设断点别只写 b 20：当前文件可能不是你要调的，明确写 b main.c:20 或 b --name main
• 多文件工程中，br list 后注意看 Location 列是否含完整路径；若显示 ???:20，说明调试信息里的路径已失效
• 修复路径映射：settings set target.source-map "/old/path" "/new/path"

Linux 上常卡在 ptrace 权限或 lldb-mi 缺失

Ubuntu/Debian 系统默认禁止非 root 进程调试其他进程，VS Code 等 GUI 工具依赖 lldb-mi（LLDB 的 GDB 兼容层），但它不在标准包里：

• 解决 ptrace 限制：echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope（临时）；或加 cap_sys_ptrace+ep 到 lldb 二进制（长期）
• lldb-mi 需手动编译：sudo apt install liblldb-17-dev 后，克隆 https://github.com/lldb-tools/lldb-mi，cmake -DLLDB_DIR=/usr/lib/llvm-17/lib/cmake/lldb ..
• 验证是否就绪：lldb-mi --version 成功输出，且 VS Code 的 launch.json 中 "miDebuggerPath" 指向它
• Clang 17 + LLDB 17 组合最稳；混用 Clang 15 + LLDB 17 可能因 DWARF 版本差异导致 p std::string 显示异常

真正容易被忽略的不是命令记不全，而是调试信息路径和优化级别的隐式耦合——改了一行 CMakeLists.txt 加了 -O2，或者把项目挪到另一台机器编译，lldb 就突然“看不懂”源码了。每次换环境，先跑一遍 readelf -wi ./app | grep DW_TAG 和 lldb ./app -o "b main" -o "r"，比翻文档快得多。