神马文学网嵌入式linux下gdbserver调试共享库
来源：百度文库 编辑：神马文学网 时间：2024/04/28 10:35:48
在开发嵌入式系统时，调试往往是一大难题。面试过不少嵌入式linux工程师，当问及调试手段时，他们的调试手段一般是两种：首先是在PC上的模拟环境中运行，若有问题，可以很方便的调试。其次，若在板子上运行时才出错，就用printf输出log信息，根据log信息定位错误。有少部分人用gdbserver调试板子上的程序，但问到如何在共享库里设置断点时，都说没有办法。
去年，Tinyx的一个内存越界BUG，花了我2天时间。gcc的一个浮点数BUG让我查了3天时间。这类BUG在PC上根本重现不了，在板子上用printf要花费大量的时间才能把错误的范围缩小一点。后来想了想，与其花时间去加printf，还不如把gdbserver调试共享库的问题解决了，可以为以后的调试节省不少时间。
在网上找了半天资料，没有什么收获，看来只好自己动手研究。花了一个周末的时间去研究gdbserver的运行方式。办法是找到了，不过仍然有点麻烦，等有时间了，修改一下gdb的代码，把这个过程自动化了。
先调试运行gdbserver，对gdbserver有了一些感性认识，然后研究linux-low.c中的代码。原来，设置断点只是在对应的内存中写入断点指令（x86上为0xcc）。
gdbserver为什么不能在共享库中设置断点呢？设置断点只是写内存，调试时，所有的代码段都是可写的，在exe中可以设置断点，没有理由不让在共享库中设置啊。所以这应该与是否是共享库关系不大。
猜测可能是符号与地址对应关系有误，如果你的本意为function1设置断点，结果gdb搞错了，设置一个毫不相干的地方，可能永远都不会执行到那里，这个断点自然没什么效果。
如果是这样，有两种方法可以解决：要么手动计算符号的地址，再设置断点，当然这样太累。另外就让gdb自动对应起来。经过反得尝试，用下列方法可以在共享库中设置断点，虽然有点麻烦，还是可行的。
1. 准备工作，编写下面几个文件：
test.c:
#include
int test(int a, int b)
{
int s = a + b;
printf("%d\n", s);
return s;
}
main.c:
#include
extern int test(int a, int b);
int main(int argc, char* argv[])
{
int s = test(10, 20);
return s;
}
Makefile:
all: so main
so:
gcc -g test.c -shared -o libtest.so
main:
gcc -g main.c -L./ -ltest -o test.exe
clean:
rm -f *.exe *.so
（为了便于演示，整个过程在PC上测试，后来证实在实验板上能够正常工作）
2. 编译并设置环境变量
make
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./
3. 运行gdbserver
gdbserver localhost:2000 ./test.exe
4. 运行gdb客户端
gdb
symbol-file test.exe
target remote localhost:2000
b main
c
5. 查看libtest.so的代码在内存中的位置。
（从gdbserver的输出或者用ps可以得到test.exe的进程ID，这里假设PID是11547）
cat /proc/11547/maps
输出：
00624000-0063e000 r-xp 00000000 03:01 718192 /lib/ld-2.3.5.so
0063e000-0063f000 r-xp 00019000 03:01 718192 /lib/ld-2.3.5.so
0063f000-00640000 rwxp 0001a000 03:01 718192 /lib/ld-2.3.5.so
00642000-00766000 r-xp 00000000 03:01 718193 /lib/libc-2.3.5.so
00766000-00768000 r-xp 00124000 03:01 718193 /lib/libc-2.3.5.so
00768000-0076a000 rwxp 00126000 03:01 718193 /lib/libc-2.3.5.so
0076a000-0076c000 rwxp 0076a000 00:00 0
00bbe000-00bbf000 r-xp 00bbe000 00:00 0
00fcc000-00fcd000 r-xp 00000000 03:01 1238761 /root/test/gdbservertest/libtest.so
00fcd000-00fce000 rwxp 00000000 03:01 1238761 /root/test/gdbservertest/libtest.so
08048000-08049000 r-xp 00000000 03:01 1238765 /root/test/gdbservertest/test.exe
08049000-0804a000 rw-p 00000000 03:01 1238765 /root/test/gdbservertest/test.exe
b7f8a000-b7f8b000 rw-p b7f8a000 00:00 0
b7f99000-b7f9a000 rw-p b7f99000 00:00 0
bfd85000-bfd9a000 rw-p bfd85000 00:00 0 [stack]
由此可以知道：libtest.so的代码在00fcc000-00fcd000之间。
6. 查看libtest.so的.text段在内存中的偏移位置：
objdump -h libtest.so |grep .text
输出：
9 .text 00000130 00000450 00000450 00000450 2**4
即偏移位置为0x00000450
7. 回到gdb窗口，加载libtest.so的符号表。
add-symbol-file libtest.so 0x00fcc450
(这里0x00fcc450 = 0x00fcc000 + 0x00000450)
8. 在共享库的函数中设置断点。
b test
9. 继续调试，可以发现在共享库中设置的断点，能够正常工作。
去年，Tinyx的一个内存越界BUG，花了我2天时间。gcc的一个浮点数BUG让我查了3天时间。这类BUG在PC上根本重现不了，在板子上用printf要花费大量的时间才能把错误的范围缩小一点。后来想了想，与其花时间去加printf，还不如把gdbserver调试共享库的问题解决了，可以为以后的调试节省不少时间。
在网上找了半天资料，没有什么收获，看来只好自己动手研究。花了一个周末的时间去研究gdbserver的运行方式。办法是找到了，不过仍然有点麻烦，等有时间了，修改一下gdb的代码，把这个过程自动化了。
先调试运行gdbserver，对gdbserver有了一些感性认识，然后研究linux-low.c中的代码。原来，设置断点只是在对应的内存中写入断点指令（x86上为0xcc）。
gdbserver为什么不能在共享库中设置断点呢？设置断点只是写内存，调试时，所有的代码段都是可写的，在exe中可以设置断点，没有理由不让在共享库中设置啊。所以这应该与是否是共享库关系不大。
猜测可能是符号与地址对应关系有误，如果你的本意为function1设置断点，结果gdb搞错了，设置一个毫不相干的地方，可能永远都不会执行到那里，这个断点自然没什么效果。
如果是这样，有两种方法可以解决：要么手动计算符号的地址，再设置断点，当然这样太累。另外就让gdb自动对应起来。经过反得尝试，用下列方法可以在共享库中设置断点，虽然有点麻烦，还是可行的。
1. 准备工作，编写下面几个文件：
test.c:
#include
int test(int a, int b)
{
int s = a + b;
printf("%d\n", s);
return s;
}
main.c:
#include
extern int test(int a, int b);
int main(int argc, char* argv[])
{
int s = test(10, 20);
return s;
}
Makefile:
all: so main
so:
gcc -g test.c -shared -o libtest.so
main:
gcc -g main.c -L./ -ltest -o test.exe
clean:
rm -f *.exe *.so
（为了便于演示，整个过程在PC上测试，后来证实在实验板上能够正常工作）
2. 编译并设置环境变量
make
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./
3. 运行gdbserver
gdbserver localhost:2000 ./test.exe
4. 运行gdb客户端
gdb
symbol-file test.exe
target remote localhost:2000
b main
c
5. 查看libtest.so的代码在内存中的位置。
（从gdbserver的输出或者用ps可以得到test.exe的进程ID，这里假设PID是11547）
cat /proc/11547/maps
输出：
00624000-0063e000 r-xp 00000000 03:01 718192 /lib/ld-2.3.5.so
0063e000-0063f000 r-xp 00019000 03:01 718192 /lib/ld-2.3.5.so
0063f000-00640000 rwxp 0001a000 03:01 718192 /lib/ld-2.3.5.so
00642000-00766000 r-xp 00000000 03:01 718193 /lib/libc-2.3.5.so
00766000-00768000 r-xp 00124000 03:01 718193 /lib/libc-2.3.5.so
00768000-0076a000 rwxp 00126000 03:01 718193 /lib/libc-2.3.5.so
0076a000-0076c000 rwxp 0076a000 00:00 0
00bbe000-00bbf000 r-xp 00bbe000 00:00 0
00fcc000-00fcd000 r-xp 00000000 03:01 1238761 /root/test/gdbservertest/libtest.so
00fcd000-00fce000 rwxp 00000000 03:01 1238761 /root/test/gdbservertest/libtest.so
08048000-08049000 r-xp 00000000 03:01 1238765 /root/test/gdbservertest/test.exe
08049000-0804a000 rw-p 00000000 03:01 1238765 /root/test/gdbservertest/test.exe
b7f8a000-b7f8b000 rw-p b7f8a000 00:00 0
b7f99000-b7f9a000 rw-p b7f99000 00:00 0
bfd85000-bfd9a000 rw-p bfd85000 00:00 0 [stack]
由此可以知道：libtest.so的代码在00fcc000-00fcd000之间。
6. 查看libtest.so的.text段在内存中的偏移位置：
objdump -h libtest.so |grep .text
输出：
9 .text 00000130 00000450 00000450 00000450 2**4
即偏移位置为0x00000450
7. 回到gdb窗口，加载libtest.so的符号表。
add-symbol-file libtest.so 0x00fcc450
(这里0x00fcc450 = 0x00fcc000 + 0x00000450)
8. 在共享库的函数中设置断点。
b test
9. 继续调试，可以发现在共享库中设置的断点，能够正常工作。
嵌入式linux下gdbserver调试共享库
嵌入式linux调试：用gdbserver调试共享库
嵌入式linux调试：用gdbserver调试共享库
linux 下创建共享库.so
嵌入式Linux的GDB远程调试的实现
远程调试你的应用程序－gdbserver
gdbserver远程调试的具体实现
Linux 共享库文件
linux下共享上网设置 shell script
Linux操作系统下的常见系统资源共享
构建嵌入式linux平台下的用户应用
构建嵌入式linux平台下的用户应用
嵌入式Linux下NAND存储系统的设计与实现hxy
关于linux下的嵌入式文件系统以及flash文件系统选择-2 - 嵌入式相关 - 无为
Linux下共享库路径配置问题[ZZ|FY] - ldong2007的专栏 - CSDN博客
Linux 调试技术
ubuntu下用samba实现windows与linux文件共享
linux下连接window xp共享HP打印机
ubuntu下用samba实现windows与linux文件共享
Windows与VMware下的Linux文件共享方式总结
Windows与VMware下的Linux文件如何实现共享
嵌入式Linux开发简介
嵌入式linux经典网站
构建嵌入式Linux系统