使用gdbserver调试共享库

Question

我在目标和CodeSourcery IDE上使用gdbserver。我的硬件是一个omap3530的软件。

我可以在主应用程序中单步执行代码，但是如果我尝试进入共享库中的函数，我会获取内存地址并终止调试器。

这是我的图书馆被编译并复制到目标系统上的/ lib文件夹。（它确实有调试符号）我已经尝试使用.gbdinit文件设置solib绝对前缀/ lib目录

下面是从gdb的跟踪警告：

903,056 13-gdb-set sysroot-on-target /lib 
903,065 13^done 
903,065 (gdb) 
903,065 14-target-select remote 192.168.1.101:2345 
903,114 =thread-group-started,id="i1",pid="42000" 
903,114 =thread-created,id="1",group-id="i1" 
903,115 15-list-thread-groups --available 
903,120 16-list-thread-groups 
903,128 &"warning: Unable to find dynamic linker breakpoint function.\nGDB will be unable to debug shared library initializers\nand track explicitly loaded dynamic code." 
903,128 &"\n" 

导致

903,395 &"Error while mapping shared library sections:\n" 
903,397 &"/lib/libCoreLib.so: Invalid argument.\n" 
903,399 =library-loaded,id="/lib/libCoreLib.so",target-name="/lib/libCoreLib.so",hostname="/lib/libCoreLib.so",low-address="0x0",high-address="0x0",symbols-loaded="0",thread-group="i1" 

Answer 1

您可以使用安装在主机上的库调试，只要debugg机器也是开发机器。在这种情况下，您使用set sysroot而不是set sysroot-on-target。例如：

set sysroot /home/username/.../rootfs/ 

其中/home/username/.../rootfs/包含您的目标文件系统

的副本我想你也应该指定在调试时遇到/，而不是/lib

Answer 2

类似的问题。调试挂断了。配置如下

主机：Ubuntu的12.04LTS

IDE：Eclipse的开普勒

目标：Beaglebone黑色/ ARM A8

OS：埃

个解决方案

更新库和包括

选择在Eclipse

• C/C++常规>路径和符号>（包括TAB）GNU C>添加>文件 的项目属性系统> /> usr从/ usr/lib/gcc/i686-linux-gnu/4/6 /包括 到/ usr/arm-linux-gnueabi/include

• C/C++常规>路径和符号>（包括TAB）GNU C++> Add>
  文件系统> /> usr /usr/arm-linux-gnueabi/include/c++/4.6。3 /臂-Linux的gnueabi

• C/C++常规>路径和符号>（库路径TAB）>添加>文件 系统> /> USR的/ usr /臂-Linux的gnueabi/lib中

Answer 3

好日子，

如果“调试文件目录”在GDB变量设置错误， 则报告的错误消息包括： 警告：无法找到动态链接程序断点功能。

目标的根文件系统在 的/ opt/ARM-Linux的gnueabihf-根文件位于我的PC主机上

以下两条命令帮助我获得远程调试使用GDB通过gdbserver的工作 （V7 .11.1）：

set debug-file-directory /opt/arm-linux-gnueabihf-rootfs/usr/lib/debug 
set sysroot /opt/arm-linux-gnueabihf-rootfs 

我已经注意到，如果“SYSROOT”在路径结尾的斜线，然后 GDB无法连接到远程目标后使用it.You会看到这个（不正确的输出） ：

Reading /lib/ld-linux-armhf.so.3 from remote target... 

或

Reading symbols from /opt/arm-linux-gnueabihf-rootfs/lib/ld-linux- 
armhf.so.3...(no debugging symbols found)...done 

而不是正确的输出：

Reading symbols from /opt/arm-linux-gnueabihf-rootfs/lib/ld-linux- 
armhf.so.3... 
Reading symbols from /opt/arm-linux-gnueabihf-rootfs/usr/lib/debug/ 
lib/arm-linux-gnueabihf/ld-2.23.so...done. 

问候， Frikkie THIRION

Answer 4

使用调试符号目标

这是最简单的方法来开展工作，并且当您开发一个特定的共享库时它特别有用。

首页复印测试可执行文件和共享库的目标与调试信息：

• 检查与readelf ----debug-dump=decodedline libmyib.so：How can I tell if a library was compiled with -g?
• 我建议用在主机NFS服务器，使编译后的输出变汇编后自动上传

然后上目标：

gdbserver --multi :1234 ./executable_name 

主持人：

arm-linux-gnueabihf-gdb -q -nh \ 
    -ex "target extended-remote target-hostname-or-ip:1234" \ 
    -ex "file ./executable_name" \ 
    -ex 'tb main' \ 
    -ex 'c' \ 
    -ex 'set solib-search-path .' 

sharedlibrary libmylib.so也适用。

我遇到的问题是gdbserver停止在动态加载器，在main之前，并且动态库尚未加载，所以GDB不知道符号在内存中的位置。

GDB似乎有一些机制来自动加载共享库符号，如果我编译为主机，并在本地运行gdbserver，则不需要运行到main。但是在ARM目标上，这是最可靠的事情。

目标gdbserver 7.12-6，主机arm-linux-gnueabihf-gdb 7.6.1来自Linaro。

而不调试符号目标库

这是常见的嵌入式目标部署之前剥去目标库，由于调试信息使得它们方式大。

例如，Buildroot默认会这样做，但您可以用BR2_STRIP_none=y将其禁用。

可以通过运行识别这样的场景：

info shared 

这都说明是这样的：

From    To     Syms Read Shared Object Library 
0x00007ffff7df7f90 0x00007ffff7dfcdd7 Yes (*)  target:/lib/ld64-uClibc.so.0 
0x00007ffff7b3a9b0 0x00007ffff7bbe05d Yes (*)  target:/lib/libc.so.0 
(*): Shared library is missing debugging information. 

所以有这两者说的调试信息缺少库的星号（*） 。

如果是这样的话，那么你必须告诉GDB使用主机上的共享库之前，他们被剥离。

Buildroot里面例如让那么容易对我们来说，因为它保持了staging目录中包含的共享库，他们被剥夺前，作为目标相同的相对路径：

set sysroot buildroot/output/staging/ 

当这个选项集，gdb立即搜索在主机而不是目标库，并在路径buildroot/output/staging/ + /lib/libc.so.0发现/lib/libc.so.0：

Reading symbols from buildroot/output/staging/lib/ld64-uClibc.so.0...done. 
Reading symbols from buildroot/output/staging/lib/libc.so.0...done. 

TODO：我不认为你可以设置多个sysroot，所以你所有的共享库必须像目标图像一样放置在正确的相对路径中。

如果检查不好默认SYSROOT，您将看到：

show sysroot 

得出：

target: 

这意味着gdb搜索在默认情况下对目标根/共享库。