我来帮你搞定远程ARM共享库的调试问题！你现在遇到attach后没法单步的情况，大概率是编译、调试服务配置或者Eclipse映射没做全，咱们一步步来捋：

这是基础中的基础！如果编译时没加调试符号，gdb根本没法关联源码和机器码。编译命令一定要加上-g（生成调试符号）和-O0（关闭优化，不然单步执行会跳来跳去，和源码行对应不上）：

arm-linux-gnueabihf-gcc -shared -fPIC -g -O0 -o libxxx.so your_source_files.c

别嫌麻烦，少了这俩参数后面全白搭！

你要调试的是加载共享库的应用，所以远程端得先让gdbserver挂到目标进程上：

• 如果应用已经在运行：先查进程ID，执行ps aux | grep target_app找到PID，然后运行：

  gdbserver :1234 --attach <目标进程PID>
  

  这里的1234是随便选的未被占用的端口，记下来后面要用。
• 如果应用还没启动：直接用gdbserver启动它，省得后续attach：

  gdbserver :1234 ./target_app
  

  注意：远程端的gdbserver必须和你的交叉编译链匹配（比如用arm-linux-gnueabihf-gdbserver，别用x86的版本）。

你之前用的是"C/C++ Attach to application"，但几个关键配置可能没到位：

• 调试器类型切换：打开Debug配置的「Debugger」选项卡，把Debugger类型改成gdbserver，然后GDB Command填gdb-multiarch（如果它不在系统环境变量里，就写绝对路径，比如/usr/bin/gdb-multiarch）。
• 远程连接设置：在「Main」选项卡，点击「Remote Connection」，新增一个「Remote TCP/IP」连接，填入目标设备的IP和刚才gdbserver用的端口（比如1234）。
• 源码与库的映射：这是最容易漏的！
  • 「Source」选项卡：点击「Add」，把你的共享库源码目录加进去，确保Eclipse能找到对应源码文件。
  • 「Debugger」选项卡的「Shared Libraries」：点击「Add」，选中本地编译出来的带调试符号的libxxx.so，然后设置远程目标上的共享库路径（比如/usr/lib/libxxx.so），让gdb能把本地的调试符号和远程运行的库关联起来。
• 启动前的GDB命令：在「Debugger」选项卡的「Startup」里，把这些命令加上（比单独的.gdbinit更靠谱）：

  set architecture arm
  set breakpoint pending on
  set solib-search-path /本地带调试符号的库所在目录
  set sysroot /你的交叉编译链sysroot路径  # 比如/opt/arm-linux-gnueabihf/sysroot，有这个能帮gdb找系统库的符号
  

因为共享库是动态加载的，直接在源码行加断点可能会提示「pending breakpoint」，这时候不用慌：

• 可以先给共享库的初始化函数加断点（比如用__attribute__((constructor))标记的函数），这样库一加载就会触发断点。
• 或者在Eclipse的Debug配置里，找到GDB设置，勾选「Allow pending breakpoints」，让gdb自动等待库加载后激活断点。
• 也可以手动在gdb命令行里设置：break libxxx.so:你的函数名，这样不管库什么时候加载，都会命中。

如果Eclipse还是不行，先抛开它，用命令行的gdb-multiarch连接试试，排除IDE的问题：

gdb-multiarch
target remote <目标设备IP>:1234
set architecture arm
set breakpoint pending on
set solib-search-path /本地带调试符号的库目录
attach <目标进程PID>  # 如果是attach模式
break your_source.c:具体行号
continue

如果命令行能正常单步，那就是Eclipse的配置没弄对，重点检查源码映射和共享库路径；如果命令行也不行，那就是编译或者gdbserver的问题，再回头检查编译参数和gdbserver版本。

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