QT Creator远程调试无法进入共享库：符号未加载问题求助

针对你用QT Creator远程调试BeagleBone Black（Jessie系统）时无法步入共享库代码的问题，结合我之前踩过的类似坑，给你几个具体的排查和解决步骤：

1. 确认共享库的调试信息完整且正确部署 #

首先得确保你的共享库真的带了完整调试信息，并且正确传到了目标机上：

• 在目标机上执行file /path/to/your/libxxx.so，输出里应该包含with debug info字样；如果没看到，说明编译时的-g参数可能没生效，或者库被用strip命令剥离了调试信息，得重新编译调试版的库。
• 用readelf -S /path/to/your/libxxx.so | grep debug检查，能看到多个以.debug开头的段（比如.debug_info、.debug_line）才说明调试信息完整。

2. 修正QT Creator的调试器路径配置 #

你提到用了set-solib-search-path，但要注意这个路径是目标机上的绝对路径，不是主机的：

• 打开QT Creator的「项目」配置页，切换到Debug模式，找到「Debugger」部分的「Additional Startup Commands」，添加：

  set solib-search-path /home/debian/your_app/libs  # 替换成目标机上共享库的实际路径
  

• 同时，确保目标机的LD_LIBRARY_PATH包含这个路径：可以在QT Creator的「Run」配置里，在「Environment」中添加LD_LIBRARY_PATH=/home/debian/your_app/libs，或者直接在目标机的~/.bashrc里添加该环境变量，保证远程连接时能正确加载库。

3. 匹配主机gdb与目标机gdbserver版本 #

版本不兼容是远程调试的常见坑：

• 在主机执行gdb --version，目标机执行gdbserver --version，两者的主版本号尽量一致（比如都是7.11.x）。如果版本差太多（比如主机是7.11，目标机是7.7），很可能导致调试符号无法正常解析。
• 如果版本不匹配，建议在目标机编译安装和主机gdb版本接近的gdbserver，或者在主机安装对应版本的gdb（Ubuntu16.04可以通过ppa或者源码编译来安装）。

4. 手动加载共享库符号 #

有时候QT Creator会自动加载符号，但如果没加载成功，可以手动操作：

• 启动远程调试后，切换到QT Creator的「Debug」视图，左侧找到「Debugger」面板下的「Loaded Symbols」，如果你的共享库显示「No symbols loaded」，右键点击它选择「Load Symbols」，可以指定本地编译的调试版库路径（因为本地的库带完整调试信息，和目标机的库符号一致）。
• 也可以在调试控制台直接执行gdb命令：

  info shared  # 查看已加载的共享库状态
  symbol-file /path/to/local/debug/libxxx.so  # 手动加载本地调试库的符号
  

5. 调整断点设置方式 #

直接在库代码里设断点可能因为库还没加载而失效，可以试试：

• 先运行到应用的主函数（比如在main()里设一个断点），等程序停在这里后，再去共享库的代码里设置断点，这时候库已经被加载，断点就能生效。
• 或者直接用gdb命令指定库和函数来设置断点：

  b libxxx.so:your_function_name
  

  这样gdb会在库加载完成后自动激活这个断点。

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