必须加-g编译生成调试信息,否则lldb无法映射源码、显示变量;核心命令为file、b、r、n、p;多文件/CMake项目需全局启用-g和Debug模式。

Clang 安装后不能直接调试,必须加 -g 编译出带调试信息的二进制文件,再用 lldb(或 gdb)加载运行。 否则 lldb 会报 No such file or directory 或无法显示源码行、变量值为空。
编译时必须加 -g,否则调试器看不到源码和变量
Clang 默认不嵌入调试信息,lldb 依赖这些信息映射机器指令到源代码行、解析类型、读取局部变量。漏掉 -g 就像给导航仪塞一张白纸地图。
-
clang -g main.c -o main:正确,生成可调试的main -
clang main.c -o main:错误,lldb ./main能启动但l(list)命令报错,p var显示(int) $0 = 0之类无意义值 - 多文件项目中,每个
.c都要加-g;用CMake时需确保CMAKE_BUILD_TYPE是Debug(而非Release)
lldb 常用调试命令不是“高级功能”,而是基础操作流
不用记全,掌握 5 个核心命令就能覆盖 90% 单步调试场景。它们是线性执行逻辑,不是独立技巧:
Clang 22.1.3 Windows 64 位历史版本安装包,适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
-
file ./main:加载可执行文件(必须第一步) -
b main.c:12:在main.c第 12 行设断点(b是breakpoint set的缩写) -
r:运行程序,停在第一个断点 -
n:逐行执行(step over),不进入函数内部 -
s:逐指令/逐函数执行(step into),遇到函数调用就跳进去 -
p var_name:打印变量当前值(po仅对 Objective-C 对象有效,C 里一律用p)
CMake 项目里调试失败,大概率是构建类型或编译器没配对
VSCode 或 CLion 中点击「调试」按钮却跳不到断点?常见原因不是 IDE 配置错,而是底层构建没生效:
- 检查
CMakeLists.txt是否有set(CMAKE_BUILD_TYPE Debug),或使用预设时是否选了debug类型(如configurePresets中"cacheVariables": {"CMAKE_BUILD_TYPE": "Debug"}) - 确认
CMAKE_C_COMPILER真的指向clang:运行cmake --build build --verbose | head -n 5,看实际调用的是不是/usr/bin/clang -g ... - CLion 用户注意:
Build > Recompile(Shift+Ctrl+F9)不会重新应用-g,必须Build > Rebuild Project或删掉cmake-build-debug目录再重载
AddressSanitizer 不是调试器,但能暴露 lldb 查不到的问题
内存越界、泄漏、重复释放这类问题,lldb 本身不报错——它只管执行流程,不管内存是否合法。这时候要换工具链:
-
clang -fsanitize=address -g -o prog prog.c:启用 ASan 并保留调试符号 -
./prog运行,崩溃时直接输出错误类型、栈帧、分配位置(比如heap-use-after-free) - ASan 报告里的行号可直接在
lldb里用l main.c:42定位,再结合p查变量状态 - 注意:ASan 会显著拖慢运行速度,仅用于排查阶段,别长期开着跑性能测试
真正卡住的地方往往不是命令记不全,而是编译阶段没埋下调试信息,或者以为「启动了调试器」就等于「能调试」——其实只是开了个壳子,里面没地图、没路标、也没坐标系。

















