GDB加载符号表慢是因默认一次性解析所有DWARF符号，超大项目应禁用auto-solib-add、正确配置solib-search-path和sourceFileMap。
为什么 GDB 加载符号表慢得像卡住
根本不是硬盘或内存不够，而是 GDB 默认行为在大型项目里“过度加载”：它会一次性尝试解析所有 .so、.a 和主可执行文件的 DWARF 符号，哪怕你只调试一个源文件。尤其当 build/ 下混着几十个模块、第三方库（如 Qt、Boost）和未 strip 的调试信息时，磁盘 I/O + 解析开销直接拖垮响应。
solib-search-path 配置错，符号就找不到
VSCode 调试器靠 launch.json 里的 setupCommands 告诉 GDB 去哪找动态库符号。常见错误是路径写死或漏掉子目录：
-
solib-search-path必须包含所有含.debug或未 strip 的.so所在目录，比如${workspaceFolder}/build/lib和${workspaceFolder}/third_party/lib - 路径之间用冒号
:分隔，不能用分号或换行 - 如果用了 CMake 的
install步骤，还得加上${workspaceFolder}/install/lib - 确认目标文件确实带调试信息：
file ./build/myapp输出里要有with debug_info
启动时跳过自动加载，需要时再手动 load
对超大项目，与其等 GDB 慢吞吞扫完全部符号，不如先禁用自动加载，进调试后再按需拉取：
- 在
launch.json的miDebuggerArgs中加：-ex "set auto-solib-add off" - 断点命中断后，在调试控制台手动执行：
sharedlibrary libxxx.so - 配合
set solib-search-path使用，否则sharedlibrary找不到文件 - 这个开关不影响主程序符号——主程序符号始终由 GDB 自动加载，只影响
.so
别让 VSCode 自己猜，显式指定 sourceFileMap
符号路径和实际源码路径不一致时（比如构建在 /tmp/build，而源码在 /home/user/project），GDB 能读到符号，但 VSCode 找不到对应源文件，表现为“源码打不开”或“断点变空心圆”。这时必须靠 sourceFileMap 映射：
立即学习“C++免费学习笔记（深入）”；
- 在
launch.json的configurations下添加："sourceFileMap": { "/tmp/build/": "${workspaceFolder}/" } - 键是编译时记录的绝对路径前缀，值是当前本地路径；多个映射用逗号分隔
- 用
readelf -w ./build/myapp | grep DW_AT_comp_dir查看编译时工作目录，确认键值是否匹配
真正卡住的往往不是 GDB 本身，而是 VSCode 在符号解析后试图把几百个文件路径一一映射到编辑器里——这步没配对，就永远卡在“Loading source…”。
