优秀的gdb图形化前端调试器

目前我自己最喜欢的还是 ddd 、 gdbgui 和 vim-vebugger插件或vimgdb插件 三种。  后来发现还有个叫 gdbida 的调试前端，听说和 gdbserver 联合调试远程进程很方便。

 

 

You could try using Insight a graphical front-end for gdb written by Red Hat Or if you use GNOME desktop environment, you can also try Nemiver.

kdbg is a graphical user interface to gdb, the GNU debugger.

ddd is a graphical front-end to gdb that is pretty nice. One of the down sides is a classic X interface, but I seem to recall it being pretty intuitive.

vim-vebugger 插件或 vimgdb 插件，也可以试试。

 

推荐使用 nemiver。insight 是 redhat 下的，ubuntu里没有更新。 ddd也不错。看自己喜好。

更推荐使用 gdb dashboard 或者 gdbgui，前者是对字符终端的重定向组合，后者是python实现的web方式的调试前端(我现在正在用的，在我的机器上，用chrome浏览器才能调式)。

https://github.com/cyrus-and/gdb-dashboard

https://github.com/cs01/gdbgui                   我现在正在用的(在我的机器上，用chrome浏览器才能调式)

https://github.com/snare/voltron                  这个可能比 gdb dashboard 还好

除了gdb dashboard之外，以下网址还提供了其它的front end（包括给gdb dashboard上色）：

https://stackoverflow.com/questions/209534/how-to-highlight-and-color-gdb-output-during-interactive-debugging/522192

 

 

 

Nemiver的安装:

基于Debian发行版，它的安装时非常直接简单，如下：

$ sudo apt-get install nemiver

在Fedora中安装如下：

$ sudo yum install nemiver 

在Arch Linux中安装如下：

$ sudo pacman -S nemiver 

Nemiver 是一款基于 GTK+ 的用于C/C++程序的图形化的独立调试器，它以GDB作为其后端。最令人赞赏的是其速度和稳定性，Nemiver是一个非常可靠，具备许多优点的调试工具。最令人欣慰的是，它能够很好地与GNOME环境像结合。

 

 

 

 

kdbg简单使用：

ubuntu下 直接 sudo apt-get install kdbg 即可安装.

若启动后出现 MNG error 11: Function is invalid at this point; chunk MHDR; subcode 0:0 错误, 那么就删除 /usr/share/kde4/apps/kdbg/icons/hicolor/22x22/actions/pulse.mng 这个文件就好了.

界面比较友好. 调试方法很简单:

1.首先g++ -g file.cpp 或  g++ --debug file.cpp  得到文件a.out 

2.运行Kdbg选择 File->Excutable 再选中a.out 这个文件,调试代码会自动载入.

3.鼠标点调试代码最左边点空白处，变红色则设置了断点,

4.按F5开始调试 F10单步 F6跳出 F7到鼠标 F8跟进。View->Locals可看变量数据。

 

 

 

ddd的问题之一：       （为什么我的 ddd 需要 root 权限才能显示源码，即便 sudo 也不能显示源码，只有 su 之后在root下才能显示源码？）

运行DDD调试器时，出现卡死现象，看软件状态，发现"waiting until GDB gets ready"。 解决办法：

用vim编辑文件 ~/.ddd/init，  将   set extended-prompt not set\n\   这行 改成： set extended-prompt (gdb) \n\       问题解决。

 

1、gdb 调式子进程：

set follow-fork-mode child

2、gdb打印预定义的宏macro的方法：

必须同时使用以下几个编译选项才能打印：

-g：

Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging information. On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but probably makes other debuggers crash or refuse to read the program. If you want to control for certain whether to generate the extra information, use -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below).

-ggdb：

Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.

-gvmslevel：   （示例： -g3， 要打印macro，请使用 -g3）

Request debugging information and also use level to specify how much information. The default level is 2. Level 0 produces no debug information at all. Thus, -g0 negates -g.

Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use -g3.

然后在gdb中使用：

info macro YOUR_MACRO 或者 macro expand YOUR_MACRO

 查看相应的macro。

 

 

gdb和gdbserver 进行远程调试

0. 为DDD设置底层调试器

有时候可能不想使用host自带的gdb进行调试，比如进行远程调试的时候。那么需要指定DDD的调试器，只需要运行的时候指定即可(确保该调试器名字不是gdb，以免与系统gdb冲突，然后将该调试器加入PATH)：

host$ ddd –-debugger m68k-elf-gdb

 

 

嵌入式Linux的GDB调试环境由Host和Target两部分组成，Host端使用arm－linux－gdb，Target Board端使用gdbserver。调试时，应用程序在嵌入式目标系统上运行，而gdb调试在Host端。gdb调试的时候，pc机上的gdb向开发板上的gdbserver发出命令，而开发板上的gdbserver就会向应用程序发出信号，使应用程序停下来或者完成其他一些工作！一般设备(非电脑)Linux发行版中都有一个可以运行的GDB，但开发人员不能直接使用该发行版中的GDB来做远程调试，而要获取GDB的源代码包，针对arm 平台作一个简单配置，重新编译得到相应GDB。Linux系统本身已经自带gdb工具，但无法用在嵌入式调试中，需要单独编译arm-linux-gdb。不过有些编译工具链可能会为x86机器提供一个已经编译好的gdb，需要自己在工具链里找一下，找到就不需要自己单独编译了。

1.角色：host和target

host是运行gdb的机器
target是运行gdbserver的机器
gdbserver提供一个网络服务，gdb remote到gdbserver上后进行调试

2. 基本要求：

• host和target可以网络通信，ping通
• host上的gdb和target上的gdbserver版本尽量一致（？）
• 编译好的可执行程序a.out，放在target上；使用'-g'选项编译；
• host上需要能访问到a.out对应的源码文件：可以是NFS共享文件，也可以是两份源码（分别放在host和target上，甚至target上不需要源码？？）

3. 基本步骤

• 编译出a.out放到target上
• target上执行：gdbserver :7788 ./a.out，其中7788是端口号可以改
• host上确保能访问到a.out对应的源码（如果是多个文件的工程，要保证目录结构也一致）
• host上执行

  cgdb
  
  target remote xx.xx.xx.xx:7788 [args]
  

  其中xx.xx.xx.xx是target的ip地址, 7788是先前在target上gdbserver对应的端口号, [args]表示参数列表，如果a.out需要传参需要在这里传入（我测试下来，host上没法传args)
• host上使用gdb命令调试

  set args -b ITENSOR -d ../dlc/bvlc_alexnet.dlc -i target_raw_list.txt -o output
  

•  

4. 源代码查看

host上应该按照target的源代码与目标文件(可执行文件)的绝对路径结构存一份一模一样的拷贝，然后这样调用：

第一种方案（当本机源码与target上的源码路径不能绝对匹配时）：

host $  ddd --debugger arm-linux-gnueabi-gdb.8.0.1  a.out
(gdb) directory  <source-code-dir>

(gdb) target remote <IP>:<port>
(gdb) load a.out

附：对于directory命令及相对路径或绝对路径的说明

因为gcc 根据你编译的时候指定的是绝对路径还是  ../../XXX.cpp之类的相对路径，在生成debug_info的时候，也把这个路径保存为debug_info 里面的文件名字，就是最后 gdb list 里面找到的文件名字。
这个可以list  查看是不是绝对路径，然后可以用命令

readelf -p .debug_str  exe_or_so_file 

看到里面保存是是完整的绝对路径。

gdb 的directory 命令添加的源码搜索路径只对相对路径的情况有效。
一个解决办法就是在gcc的时候，使用相对路径那么gdb里面你就可以使用 dir来设置了。像些CMake之类的，它喜欢使用绝对路径，有人可以写个脚本让它使用相对路径，参考 http://stackoverflow.com/questions/9607155/make-gcc-put-relative-filenames-in-debug-information
如果gcc里面-g  生成的debug_info 使用的绝对路径了，最简单的办法就是你把源码也放到相应的位置上去了。
但如果你不想使用这个绝对路径，那也还是有办法的。 
GDB还提供另外一个选择，可以让你修改源码搜索路径，把源码绝对路径里面的一个path映射到另一个path上去，这样即使你debug info了里面的是绝对路径，源码也可以放到另外的目录。
这就是命令

set substitute-path from_path  to_path

比如 list显示的源码是   /home/aaa/1.cpp

那么设置了 set substitute-path /home/aaa/   /home/bbb/
之后，即使你的源文件1.cpp 放在 /home/bbb下面也是可以找到的了。因为gdb帮你做了字符串替换。 

 

或者第二种方案（本机源码与target上的源码 绝对路径结构一模一样时）：

host $  ddd --debugger arm-linux-gnueabi-gdb.8.0.1  a.out
(gdb) target remote <IP>:<port>
(gdb) load a.out

 

或者第三种方案：

host$  gdb
(gdb) target remote <IP>:<port>
(gdb) load <executable>
(gdb) file <executable>
   gdb should know symbols now
(gdb) b main
(gdb) mon reset
(gdb) contnue
   it should break at main
(gdb) bt

 

 

嵌入式Linux的GDB调试环境由Host和Target两部分组成，Host端使用arm－linux－gdb，Target Board端使用gdbserver。这样，应用程序在嵌入式目标系统上运行，而gdb调试在Host端，所以要采用远程调试（remote）的方法。进行GDB调试，目标系统必须包括gdbserver程序（在主机上正对硬件平台编译成功后下载到目标机上），宿主机也必须安装GDB 程序。一般Linux发行版中都有一个可以运行的GDB，但开发人员不能直接使用该发行版中的GDB来做远程调试，而要获取GDB的源代码包，针对arm 平台作一个简单配置，重新编译得到相应GDB。GDB的源代码包可以从

http://www.gnu.org/software/gdb/download/

http://ftp.gnu.org/gnu/gdb/   211.95.105.202：3128可以上去的，所有的版本都有啊

http: //ftp.cs.pu.edu.tw/linux/sourceware/gdb/releases/下载

ftp://ftp.gnu.org/gnu/gdb

外网的ftp我经常上不去，国内常见的开源社区的下载频道通常都有下载的http://download.chinaunix.net/download/0004000/3482.shtml，最新版本为gdb-6.5.tar.bz2。下载到某个目录，笔者下载到/opt/。但要注意，gdb的版本需要和croostool 相匹配。

配置编译及安装下载

下载完后，进入/opt/目录，配置编译步骤如下：

#tar jxvf gdb-6.5-tar-bz2
#cd gdb-6.5
#./configure --target=arm-linux --prefix=/usr/local/arm-gdb –v
（--target配置gdb的目标平台，--prefix配置安装路径，当然其他路径也可以， .跟下面配置一致即可，须在环境变量中声明，启动arm-linux-gdb需要，可更改/etc/profile或~/.bash_profile或~/.bashrc，添加export PATH=$PATH:/usr/local/arm-gdb/bin，这样可以找到路径）
#make

#make install
（生成arm-linux-gdb,并存入/usr/local/arm-gdb /bin/，查询确认下）
也可以启动arm-linux-gdb，若成功，则证明安装无误
进入gdb/gdbserver目录：
[root@dding gdbserver]# pwd
/opt/gdb-6.5/gdb/gdbserver
[root@dding gdbserver]# 必须在gdbserver目录下运行配置命令，此时才能用相对路径
#./configure --target=arm-linux --host=arm-linux
（--target=arm-linux表示目标平台，--host表示主机端运行的是arm-linux-gdb，不需要配置—prefix，因为gdbserver不在主机端安装运行）
#make CC=/usr/local/arm/2.95.3/bin/arm-linux-gcc
(这一步要指定你自己的arm-linux-gcc的绝对位置，我试过相对的不行，提示make: arm-linux-gcc: Command not found，可好多人都用的相对路径，即直接赋值arm-linux-gcc，可采取make时传递参数，也可以直接修改gdbserver目录下的Makefile文件中的环境变量CC)

 

http://davis.lbl.gov/Manuals/GDB/gdb_17.html

gdbserver is a control program for Unix-like systems, which allows you to connect your program with a remote GDB via target remote---but without linking in the usual debugging stub.

gdbserver is not a complete replacement for the debugging stubs, because it requires essentially the same operating-system facilities that GDB itself does. In fact, a system that can run gdbserver to connect to a remote GDB could also run GDB locally! gdbserver is sometimes useful nevertheless, because it is a much smaller program than GDB itself. It is also easier to port than all of GDB, so you may be able to get started more quickly on a new system by using gdbserver. Finally, if you develop code for real-time systems, you may find that the tradeoffs involved in real-time operation make it more convenient to do as much development work as possible on another system, for example by cross-compiling. You can use gdbserver to make a similar choice for debugging.

GDB and gdbserver communicate via either a serial line or a TCP connection, using the standard GDB remote serial protocol.

On the target machine,you need to have a copy of the program you want to debug. gdbserver does not need your program's symbol table, so you can strip the program if necessary to save space. GDB on the host system does all the symbol handling.

To use the server, you must tell it how to communicate with GDB; the name of your program; and the arguments for your program. The usual syntax is:

target> gdbserver comm program [ args ... ]

comm is either a device name (to use a serial line) or a TCP hostname and portnumber. For example, to debug Emacs with the argument `foo.txt' and communicate with GDB over the serial port `/dev/com1':

target> gdbserver /dev/com1 emacs foo.txt

gdbserver waits passively for the host GDB to communicate with it.

To use a TCP connection instead of a serial line:

target> gdbserver host:2345 emacs foo.txt

The only difference from the previous example is the first argument, specifying that you are communicating with the host GDB via TCP. The `host:2345' argument means that gdbserver is to expect a TCP connection from machine `host' to local TCP port 2345. (Currently, the `host'part is ignored.) You can choose any number you want for the port number as long as it does not conflict with any TCP ports already in use on the target system (for example, 23 is reserved for telnet).(5) You must use the same port number with the host GDB target remote command.

On some targets, gdbserver can also attach to running programs. This is accomplished via the --attach argument. The syntax is:

target> gdbserver comm --attach pid

pid is the process ID of a currently running process. It isn't necessary to point gdbserver at a binary for the running process.

 

On the GDB host machine,you need an unstripped copy of your program, since GDB needs symbols and debugging information. Start up GDB as usual, using the name of the local copy of your program as the first argument. (You may also need the 

`--baud'

 option if the serial line is running at anything other than 9600bps.) After that, use target remote to establish communications with gdbserver. Its argument is either a device name (usually a serial device, like `/dev/ttyb'), or a TCP port descriptor in the form host:PORT. For example:

(gdb) target remote /dev/ttyb

communicates with the server via serial line `/dev/ttyb', and

(gdb) target remote the-target:2345

communicates via a TCP connection to port 2345 on host `the-target'. For TCP connections, you must start up gdbserver prior to using the target remote command. Otherwise you may get an error whose text depends on the host system, but which usually looks something like`Connection refused'.

 

 

 

 

----------------------------------------------------------------------------------------------------------

OpenOCD（Open On-Chip Debugger）开源片上调试器，是一款开源软件，最初是由Dominic Rath同学还在大学期间发起的（2005年）项目。OpenOCD旨在提供针对嵌入式设备的调试、系统编程和边界扫描功能。

OpenOCD的功能是在仿真器的辅助下完成的，仿真器是能够提供调试目标的电信号的小型硬件单元。仿真器是必须的，因为调试主机（运行OpenOCD的主机）通常不具备这种电信号的直接解析功能。

仿真器支持一个或多个传输协议，每个协议涉及不同的电信号，且使用不同的协议栈进行消息传递。市面上有很多种仿真器，并且这些仿真器的命名没有统一的规律。