跳至主要内容

【转】使用gdbserver远程调试

1.默认crosstool交叉编译器没有自带gdbserver,需要自行编译
到GNU官方FTP下载,目前最新版的是gdb-6.7.1
下载地址:http://ftp.gnu.org/gnu/gdb/
注:若已有gdbserver,可以直接跳到步骤4
 
2.编译gdbserver
编译GDB源码时只需要编译出gdbserver就可以了,交叉编译器自带arm-linux-gdb(client端)可以使用。
gdb-6.7.1
# cd gdb-6.7.1/gdb/gdbserver/
#./configure --host=arm-linux --prefix=/work/install/gdbserver
#make
#make install
这时会在/work/install/gdbserver目录下生成bin/gdbserver,将其拷贝到nfs文件系统
#cd /work/install/gdbserver
#cp bin/gdbserver /work/nfs/rootfs/bin
 
3.库问题
这里需要注意的是运行gdbserver还需要libthread_db库,若你自己做的文件系统内没有这个库的话需要从交叉编译器内拷一个过去。
# gdbserver -h (target)
gdbserver: error while loading shared libraries: libthread_db.so.1: cannot open shared object file: No such file or directory
# cp -avf lib/libthread_db* /work/nfs/rootfs_bluetooth_omap/lib/
`/lib/libthread_db-1.0.so' -> `/work/nfs/rootfs/lib/libthread_db-1.0.so'
`/lib/libthread_db.so.1' -> `/work/nfs/rootfs/lib/libthread_db.so.1'
注:若不知道缺少什么库可以根据运行时错误提示拷贝或者用先用strace跟踪一下:
#strace -f -F -o strace.log gdbserver -h
#vi strace.log 
发现如下字段:
872   writev(2, [{"gdbserver", 9}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"libthread_db.so.1", 17}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10) = 126
872   exit_group(127)                   = ?
得知缺少libthread_db.so.1库(红色部分标出)。
 
4.调试过程
1)Target端建立远程调试服务
# gdbserver 192.168.167.170:1234 obexftp (target)
Process obexftp created; pid = 858
Listening on port 1234
 
2)Host端GDB加载要调试的程序
这里要调试的程序得是交叉编译过的,并且加了-g参数。不过大部分编译程序默认就是加了-g参数的,这点可以从编译时的log看出。
# arm-linux-gdb obexftp 
GNU gdb 6.6.50.20070301 (MontaVista 6.6.50-2.0.1.0702865 2007-03-26)
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=armv5tl-montavista-linux-gnueabi"...
 
3)连接到目标板调试服务
(gdb) target remote 192.168.167.15:1234
Remote debugging using 192.168.167.15:1234
Error while reading shared library symbols:
Dwarf Error: Can't read DWARF data from '/opt/montavista/pro/devkit/arm/v5t_le/target/usr/lib/debug/lib/ld-2.5.90.so.debug'
0x400007a0 in _start () from /opt/montavista/pro/devkit/arm/v5t_le/target/lib/ld-linux.so.3
注:上面两行错误信息暂时不用管,原因还不清楚,但是暂时发现不影响使用。
连接成功后ARM板上的信息应该是这样的:
# ./gdbserver 192.168.0.29:1234 arm0702_8.out
Process arm0702_8.out created; pid = 228
Remote debugging from host 192.168.0.29  <----多出这一行
上面这行表示宿主机和开发板连接成功。现在我们就可以在Host端像调试本地程序一样调试ARM板上程序。不过,需要注意的是这里执行程序要用"c",不能用"r"。因为程序已经在Target Board上面由gdbserver启动了。

调试过程如下:
(gdb) b main
Breakpoint 1 at 0x9870: file obexftp.c, line 376.
(gdb) info b
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x00009870 in main at obexftp.c:376
(gdb) c
Continuing.
Error while mapping shared library sections:
/work/install/bluetooth//lib/libobexftp.so.0: No such file or directory.
Error while mapping shared library sections:
/work/install/bluetooth//lib/libc.so.6: No such file or directory.
Breakpoint 1, main (argc=1, argv=0xbed0dec4) at obexftp.c:384
384             if (strstr(argv[0], "ls") != NULL)      most_recent_cmd = 'l';
(gdb)
若产生这个错误主要是由于该调试的应用程序使用到了额外的库,而这个库在gdb默认的搜索路径内没有
(相对与远程调试,gdb默认搜索的路径即为交叉编译器的库路径,下面我会介绍到)
因此,这里我们需要修改一下gdb默认的共享库搜索路径。
修改的办法是设置GDB的环境变量:
(gdb) show solib-absolute-prefix
The current system root is "/opt/montavista/pro/devkit/arm/v5t_le/target". 
上面这个路径即GDB默认的绝对搜索路径,即交叉编译器库路径
(gdb) show solib-search-path
The search path for loading non-absolute shared library symbol files is .
(gdb) set solib-search-path /work/install/bluetooth/lib
这个路径为若在solib-absolute-prefix指定的路径内没有搜索到库,则再继续尝试从该路径进行搜索。
这点倒有点类似于系统默认库搜索路径与LD_LIBRARY_PATH的关系。
详细参考GDB手册中相关部分:
http://wiki.chinaunix.net/index.php/GDB_Manual_15_1

设置好solib-search-path后再运行程序:
(gdb) set solib-search-path /work/install/bluetooth/lib/
(gdb) c
Continuing.
Error while reading shared library symbols:
Dwarf Error: Can't read DWARF data from '/opt/montavista/pro/devkit/arm/v5t_le/target/usr/lib/debug/lib/ld-2.5.90.so.debug'
Breakpoint 1, main (argc=1, argv=0xbe896eb4) at obexftp.c:384
384             if (strstr(argv[0], "ls") != NULL)      most_recent_cmd = 'l';
(gdb) l
379             char *output_file = NULL;
380             char *move_src = NULL;
381             /* char *inbox; */
382
383             /* preset mode of operation depending on our name */
384             if (strstr(argv[0], "ls") != NULL)      most_recent_cmd = 'l';
385             if (strstr(argv[0], "get") != NULL)     most_recent_cmd = 'g';
386             if (strstr(argv[0], "put") != NULL)     most_recent_cmd = 'p';
387             if (strstr(argv[0], "rm") != NULL)      most_recent_cmd = 'k';
388
(gdb)
运行成功
 
 
注:使用GDB调试时查看代码不是很方便。CLWEN使用VIM作为GDB前端界面,结合gdb的远程调试功能,动态的将程序当前运行的代码显示在VIM上,查看起来十分方便。其远程调试方法和GDB+GDB Server一样,但是多了一个GUI界面(VIM)。
参考:《使用CLEWN远程调试》

评论

此博客中的热门博文

【转】AMBA、AHB、APB总线简介

AMBA 简介 随着深亚微米工艺技术日益成熟,集成电路芯片的规模越来越大。数字IC从基于时序驱动的设计方法,发展到基于IP复用的设计方法,并在SOC设计中得到了广泛应用。在基于IP复用的SoC设计中,片上总线设计是最关键的问题。为此,业界出现了很多片上总线标准。其中,由ARM公司推出的AMBA片上总线受到了广大IP开发商和SoC系统集成者的青睐,已成为一种流行的工业标准片上结构。AMBA规范主要包括了AHB(Advanced High performance Bus)系统总线和APB(Advanced Peripheral Bus)外围总线。   AMBA 片上总线        AMBA 2.0 规范包括四个部分:AHB、ASB、APB和Test Methodology。AHB的相互连接采用了传统的带有主模块和从模块的共享总线,接口与互连功能分离,这对芯片上模块之间的互连具有重要意义。AMBA已不仅是一种总线,更是一种带有接口模块的互连体系。下面将简要介绍比较重要的AHB和APB总线。 基于 AMBA 的片上系统        一个典型的基于AMBA总线的系统框图如图3所示。        大多数挂在总线上的模块(包括处理器)只是单一属性的功能模块:主模块或者从模块。主模块是向从模块发出读写操作的模块,如CPU,DSP等;从模块是接受命令并做出反应的模块,如片上的RAM,AHB/APB 桥等。另外,还有一些模块同时具有两种属性,例如直接存储器存取(DMA)在被编程时是从模块,但在系统读传输数据时必须是主模块。如果总线上存在多个主模块,就需要仲裁器来决定如何控制各种主模块对总线的访问。虽然仲裁规范是AMBA总线规范中的一部分,但具体使用的算法由RTL设计工程师决定,其中两个最常用的算法是固定优先级算法和循环制算法。AHB总线上最多可以有16个主模块和任意多个从模块,如果主模块数目大于16,则需再加一层结构(具体参阅ARM公司推出的Multi-layer AHB规范)。APB 桥既是APB总线上唯一的主模块,也是AHB系统总线上的从模块。其主要功能是锁存来自AHB系统总...

【转】VxWorks入门

1.VxWorks开发方式:交叉开发,即将开发分为主机(host)和目标机(target)两部分。 类似于dos下C语言程序的开发。 合并开发的优点:简单 缺点:资源消耗量大,CPU支持,非标准体系的支持 host (Tornado) target(vxWork) 小程序模块 vxWorks实际采用开发模式 Tornado提供:编辑,编译,调试,性能分析工具,是vxWorks的开发工具 vxWorks:面向对象可以剪裁的实际运行操作系统 2.vxWorks启动方式 <1>Rom方式 (vxWork_rom) vxWorks直接烧入rom <2>Rom引导方式(bootrom+vxWorks) 其中bootrom烧入rom,vxWorks可以通过从串口,网口,硬盘,flash等下载!这里的bootrom不是开发环境中的bootable,在开发环境里bootable指的是vxWorks,downloadable指application 3.调试 <1>attachs/20060907_164540_564.rar 用来在多任务调试时将调试对象绑定到某个任务 <2>任务级调试(attachs/20060907_164540_564.rar taskName) 单个任务的调试不会影响到其他任务的运行,主要用来调用户的应用程序。 全局断点:在调另一任务或本任务时,系统运行本任务断点,则停下。各任务要配合使用。 任务断点:调本任务时,系统运行到本任务断点,则停下。如果没有attachs/20060907_164540_564.rar到本任务,不起作用。 一次性断点:跑到一次之后自动删除。 <3>系统级调试(attachs/20060907_164540_564.rar system) 把所有task和系统core、中断看成一个整体,可用于调试系统和中断。对中断调试,如果不是系统级调试,无论是那种断点都不起作用 !wdbAgent不在调试范围内,当任务级调试时工作在中断方式,系统级调试工作在轮询方式。 !可是使用命令行方式的调试,参看crossWind教程。 4.调度 优先级调度(无条件) 时间片:同优先级,如果时间片没有打开,任务采取先到先运行,运行完毕在交出cpu,如果打开,则轮流使用cpu。 !死循环使比它...

【转】C++/CLI程序进程之间的通讯

 现在,把大型软件项目分解为一些相交互的小程序似乎变得越来越普遍,程序各部分之间的通讯可使用某种类型的通讯协议,这些程序可能运行在不同的机器上、不同的操作系统中、以不同的语言编写,但也有可能只在同一台机器上,实际上,这些程序可看成是同一程序中的不同线程。而本文主要讨论C++/CLI程序间的通讯,当然,在此是讨论进程间通讯,而不是网络通讯。    简介   试想一个包含数据库查询功能的应用,通常有一个被称为服务端的程序,等待另一个被称为客户端程序发送请求,当接收到请求时,服务端执行相应功能,并把结果(或者错误信息)返回给客户端。在许多情况中,有着多个客户端,所有的请求都会在同一时间发送到同一服务端,这就要求服务端程序要更加高级、完善。   在某些针对此任务的环境中,服务端程序可能只是众多程序中的一个程序,其他可能也是服务端或者客户端程序,实际上,如果我们的数据库服务端需要访问不存在于本机的文件,那么它就可能成为其他某个文件服务器的一个客户端。一个程序中可能会有一个服务线程及一个或多个客户线程,因此,我们需小心使用客户端及服务端这个术语,虽然它们表达了近似的抽象含义,但在具体实现上却大不相同。从一般的观点来看,客户端即为服务端所提供服务的"消费者",而服务端也能成为其他某些服务的客户端。    服务端套接字   让我们从一个具体有代表性的服务端程序开始(请看例1),此程序等待客户端发送一对整数,把它们相加之后返回结果给客户端。   例1: using namespace System; using namespace System::IO; using namespace System::Net; using namespace System::Net::Sockets; int main(array<String^>^ argv) { if (argv->Length != 1) { Console::WriteLine("Usage: Server port"); Environment::Exit(1); } int port = 0; try { port = Int32::Parse(argv[0]); } catch (FormatException^ e) { Console::Wri...