LLDB无法在含调试信息的共享库中定位断点求助

以下是针对该问题的具体排查方向：

• 检查共享库加载时机

  • 调试启动后执行LLDB命令 image list，确认目标共享库是否已被加载。如果库是通过dlopen动态延迟加载的，断点会处于pending状态，需在dlopen调用处设断点，等库实际加载后再尝试设置目标断点。
  • 手动执行 process load <目标库绝对路径> 强制加载库，再尝试设置断点验证效果。

• 验证调试信息完整性与路径匹配

  • 用 objdump --dwarf=info <目标库文件> 查看DWARF调试信息，确认hud_crosshair.cpp文件及行号47的调试条目是否存在。若条目缺失，说明编译阶段调试信息生成异常。
  • 执行 readelf -wi <目标库文件> 检查调试信息中的源码路径，确认是否与本地源码路径一致。若路径不匹配，通过LLDB命令 settings set target.source-map <编译时记录的路径> <本地实际源码路径> 进行路径映射。

• 核对编译链接参数

  • 确认这两个库的CMake配置中，是否正确设置了CMAKE_BUILD_TYPE=Debug，或CMAKE_CXX_FLAGS包含-g参数（避免使用-g0）。即使file命令显示存在debug_info，也可能因调试信息级别不足导致断点无法解析。
  • 检查链接参数是否包含-Wl,--no-rosegment等可能破坏调试信息关联的优化选项，尝试移除后重新构建。

• 测试原生调试工具的表现

  • 脱离VS Codium，直接用LLDB启动可执行文件：lldb ./<可执行文件>，执行 break set -f hud_crosshair.cpp -l 47 验证断点是否能设置成功。若原生LLDB也失败，问题出在库或调试信息本身；若成功，则是VS Codium的配置问题。
  • 用GDB对比测试：gdb ./<可执行文件> 设置相同断点，若GDB能正常命中，说明是LLDB对该库调试信息的兼容性问题。

• 排查系统与调试工具兼容性

  • 替换CodeLLDB自带的LLDB为系统原生版本：通过apt install lldb安装系统LLDB，在VS Codium的CodeLLDB设置中修改lldb.executablePath指向系统LLDB路径（如/usr/bin/lldb），重试调试。
  • 检查内核ptrace权限：执行 sysctl kernel.yama.ptrace_scope，若值为1或2，临时设置为0：sudo sysctl -w kernel.yama.ptrace_scope=0，再尝试调试。

• 检查文件系统与权限

  • 确认目标库文件和源码文件的读取权限正常，LLDB进程拥有访问权限。
  • 若库文件存储在FUSE文件系统（如远程挂载、Snap容器路径），尝试将库文件复制到本地普通文件系统（如/home目录）后重试调试。

内容的提问来源于stack exchange，提问作者NoodleCollie