1. 深度linux V20如何安装gdb，如何用gdb调试程序、用gdb设置断点删除断点、gdb自动显示变量值、看内存值
因本人通过几个小时的时间才解决这个问题，希望我的答案能节省大部分初学者在gdb上的时间。我也是今天才接触gdb，以下是有关深度linux V20的gdb调试问题的初步总结：
安装gdb方式，sudo apt-get install gdb ，有ok点击ok安装，直到安装结束。
gcc -g aa.c之后才能调试a.out文件。(aa.c表示你的源文件)
用法gdb a.out或者gdb进入后file a.out
l N是查看N行附近的代码，直接l是显示接下去的代码。r运行过程中遇到断点，按l则显示断点附近代码。
l 函数名是查看函数名里边的代码
q退出调试。
p 变量，查看变量即时值。
r运行。
n单步执行。
s单步执行-进入函数。
c连续多步运行，直到下个断点（循环的下一次断点）暂停。
b N第N行设置断点。
b 函数名，在函数名的入口处设置断点。
b 文件名:行号，在指定文件名行号设置断点。其中文件名是源文件的文件名。
(条件断点)b 行号 if 变量==N，表示该行号的断点必须满足变量==N的条件下才停下来。
ignore 断点编号 N，表示该断点编号在接下来的运行过程中忽略N次，即第N+1次该断点才会停下来。
info break显示全部断点。简写i b
delete 1-3删除编号为1到3的断点。简写 d 1-3。d 4只删除编号为4的断点。
delete break删除所有断点。无法简写
clear 20删除20行断点。
运行中disable break n 禁用断点号为n的断点。enable break n 使能断点为n的断点号重新启用。其中break可以简写为b
display {var1,var2,var3}自动显示var1～3变量的值。要删除display则用delete display N，N表示display的编号，如果不加N则表示删除全部的display。如果要自动显示数组内容，用display 数组名。注意：display需要r之后才能设置。
watch {var1,var2,var3}自动跟踪改变的值，只要有改变才显示watch。要删除watch，用d N，N代表watch编号，用i b可以查看该编号。注意：watch需要r之后才能设置。
gdb死循环程序按键盘ctrl+c可结束程序
****************
要查看内存地址的内容用x /nfu 内存地址。以下是n、f、u的解释
其中n表示要显示多少个内存单元。
f表示显示方式, 可取如下值
x 按十六进制格式显示变量。
d 按十进制格式显示变量。
u 按十进制格式显示无符号整型。
o 按八进制格式显示变量。
t 按二进制格式显示变量。
a 按十六进制格式显示变量。
i 指令地址格式
c 按字符格式显示变量。
f 按浮点数格式显示变量。
u表示一个地址单元的长度
b表示单字节，
h表示双字节，
w表示四字节，
g表示八字节
*****************
2. linux中怎么使用gdb调试进程有dettach
在2.5.60版Linux内核及以后，GDB对使用fork/vfork创建子进程的程序提供了follow-fork-mode选项来支持多进程调试。 follow-fork-mode的用法为： set follow-fork-mode [parentchild] parent: fork之后继续调试父进程，子进程不受影响。 child: fork之后调试子进程，父进程不受影响。 因此如果需要调试子进程，在启动gdb后： (gdb) set follow-fork-mode child并在子进程代码设置断点。 此外还有detach-on-fork参数，指示GDB在fork之后是否断开（detach）某个进程的调试，或者都交由GDB控制： set detach-on-fork [onoff] on: 断开调试follow-fork-mode指定的进程。 off: gdb将控制父进程和子进程。follow-fork-mode指定的进程将被调试，另一个进程置于暂停（suspended）状态。 注意，最好使用GDB 6.6或以上版本，如果你使用的是GDB6.4，就只有follow-fork-mode模式。 follow-fork-mode/detach-on-fork的使用还是比较简单的，但由于其系统内核/gdb版本限制，我们只能在符合要求的系统上才能使用。而且，由于follow-fork-mode的调试必然是从父进程开始的，对于fork多次，以至于出现孙进程或曾孙进程的系统，例如上图3进程系统，调试起来并不方便。 Attach子进程 众所周知，GDB有附着（attach）到正在运行的进程的功能，即attach <pid>命令。因此我们可以利用该命令attach到子进程然后进行调试。 例如我们要调试某个进程RIM_Oracle_Agent.9i，首先得到该进程的pid [root@tivf09 tianq]# ps -efgrep RIM_Oracle_Agent.9i nobody 6722 6721 0 05:57 ? 00:00:00 RIM_Oracle_Agent.9i root 7541 27816 0 06:10 pts/3 00:00:00 grep -i rim_oracle_agent.9i通过pstree可以看到，这是一个三进程系统，oserv是RIM_Oracle_prog的父进程，RIM_Oracle_prog又是RIM_Oracle_Agent.9i的父进程。 [root@tivf09 root]# pstree -H 6722通过 pstree 察看进程 启动GDB，attach到该进程 用 GDB 连接进程 现在就可以调试了。一个新的问题是，子进程一直在运行，attach上去后都不知道运行到哪里了。有没有办法解决呢？ 一个办法是，在要调试的子进程初始代码中，比如main函数开始处，加入一段特殊代码，使子进程在某个条件成立时便循环睡眠等待，attach到进程后在该代码段后设上断点，再把成立的条件取消，使代码可以继续执行下去。 至于这段代码所采用的条件，看你的偏好了。比如我们可以检查一个指定的环境变量的值，或者检查一个特定的文件存不存在。以文件为例，其形式可以如下： void debug_wait(char *tag_file) { while(1) { if (tag_file存在) 睡眠一段时间; else break; } }当attach到进程后，在该段代码之后设上断点，再把该文件删除就OK了。当然你也可以采用其他的条件或形式，只要这个条件可以设置/检测即可。 Attach进程方法还是很方便的，它能够应付各种各样复杂的进程系统，比如孙子/曾孙进程，比如守护进程（daemon process），唯一需要的就是加入一小段代码。 GDB wrapper 很多时候，父进程 fork 出子进程，子进程会紧接着调用 exec族函数来执行新的代码。对于这种情况，我们也可以使用gdb wrapper 方法。它的优点是不用添加额外代码。 其基本原理是以gdb调用待执行代码作为一个新的整体来被exec函数执行，使得待执行代码始终处于gdb的控制中，这样我们自然能够调试该子进程代码。 还是上面那个例子，RIM_Oracle_prog fork出子进程后将紧接着执行RIM_Oracle_Agent.9i的二进制代码文件。我们将该文件重命名为RIM_Oracle_Agent.9i.binary，并新建一个名为RIM_Oracle_Agent.9i的shell脚本文件，其内容如下： [root@tivf09 bin]# mv RIM_Oracle_Agent.9i RIM_Oracle_Agent.9i.binary [root@tivf09 bin]# cat RIM_Oracle_Agent.9i #!/bin/sh gdb RIM_Oracle_Agent.binary当fork的子进程执行名为RIM_Oracle_Agent.9i的文件时，gdb会被首先启动，使得要调试的代码处于gdb控制之下。
3. Linux内核调试工具KGDB
内核工具KGDB调试环境需要为Linux 内核加上 kgdb补丁，补丁实现GDB远程调试所需要的功能，包括命令处理、陷阱处理及串口通信3个主要的部分。KGDB补丁的主要作用是在Linux 内核中添加了一个调试Stub。调试Stub是Linux 内核中的一小段代码，是运行GDB的开发机和所调试内核之间的一个媒介。GDB和调试stub之间通过GDB串行协议进行通信。GDB串行协议是-种基于消息的ASCII 码协议，包含了各种调试命令。当设置断点时,KGDB将断点的指令替换为一条 trap指令，当执行到断点时控制权就转移到调试 stub中去。此时，调试stub 的任务就是使用远程串行通信协议将当前环境传送给GDB，然后从GDB处接收命令。GDB命令告诉stub 下一步该做什么，当stub收到继续执行的命令时，将恢复程序的运行环境，把对 CPU的控制权重新交还给内核。KGDB补丁给内核添加以下3个部件：
(1 ) GDB stub
GDB stub被称为调试插桩（简称为stub)，是KGDB调试器的核心。它是Linux内核中的一小段代码，用来处理主机上: GDB发来的各种请求;并且在内核处于被调试状态时，控制目标机板上的处理器。
(2）修改异常处理函数
当这个异常发生时，内核将控制权交给KGDB调试器，程序进入KGDB提供的异常处理函数中。在里面，可以分析程序的各种情况。
(3)串口通信
GDB和 stub之间通过GDB串行协议进行通信。它是一种基于消息的ASCII 码协议，包含了各种调试命令。除串口外，也可以使用网卡进行通信。以设置内核断点为例说明KGDB与GDB之间的工作过程。设置断点时，KGDB修改内核代码，将断点位置的指令替换成一条异常指令(在ARM中这是一条未定义的指令)。当执行到断点时发生异常，控制权转移到stub 的异常处理函数中。此时，stub的任务就是使用GDB串行通信协议将当前环境传送给GDB，然后从GDB处接收命令，GDB命令告诉stub下一步该做什么。当stub收到继续执行的命令时，将恢复原来替换的指令、恢复程序的运行环境，把对CPU的控制权重新交还给内核。
4. 如何使用gdb调试linux kernel
gdb是用来调试二进制程序的，不能调试python脚本。 python自带pdb模块，可以用来调试自己的脚本。 使用python -m pdb ，交互方式，命令与gdb类似。
5. gdb调试(ARM+Linux)中的gdbserver该怎么理解呢
1、ARM硬件内核嵌入了能够响应J－Link命令的调试模块（用户无法修改，也不需要额外烧录程序）；
2、在调试过程是，由ARM内嵌的调试模块来执行和响应Linux下的gdb调试软件（工具），所以有些人把它称为gdbserver；
3、而linux中的软件很多都是服务器+用户的模式（不明白的可以直接忽略这个表述），Linux中的gdb在自己的软件架构有一个虚拟的服务器（就是上图中的GDB Server），其与博客上的gdbserver不是一个东东；
4、我个人也不认同有些博客中的那种说法，但也不能说他们是错的，因为从宏观的角度讲，ARM硬件内核嵌入调试模块正是为gdb服务的，因此称之为gdbserver也有些道理，只不过这样一来，给造成不必要的误解！
******希望我的解释对你有帮助！
6. Linux：如何使用gdb调试多进程多线程程序
follow-fork-mode
在2.5.60版Linux内核及以后，GDB对使用fork/vfork创建子进程的程序提供了follow-fork-mode选项来支持多进程调试。
follow-fork-mode的用法为：
set follow-fork-mode [parent|child]
parent: fork之后继续调试父进程，子进程不受影响。
child: fork之后调试子进程，父进程不受影响。
因此如果需要调试子进程，在启动gdb后：
(gdb) set follow-fork-mode child
并在子进程代码设置断点。
此外还有detach-on-fork参数，指示GDB在fork之后是否断开（detach）某个进程的调试，或者都交由GDB控制：
set detach-on-fork [on|off]
on: 断开调试follow-fork-mode指定的进程。
off: gdb将控制父进程和子进程。follow-fork-mode指定的进程将被调试，另一个进程置于暂停（suspended）状态。
注意，最好使用GDB 6.6或以上版本，如果你使用的是GDB6.4，就只有follow-fork-mode模式。
follow-fork-mode/detach-on-fork的使用还是比较简单的，但由于其系统内核/gdb版本限制，我们只能在符合要求的系统上才能使用。而且，由于follow-fork-mode的调试必然是从父进程开始的，对于fork多次，以至于出现孙进程或曾孙进程的系统，例如上图3进程系统，调试起来并不方便。
7. linux内核漏洞分析实战 看看专家是怎么一步步用gdb kgdb调试linux内核驱动的
Linux内核调试方法
kdb：只能在汇编代码级进行调试；
优点是不需要两台机器进行调试。
gdb：在调试模块时缺少一些至关重要的功能，它可用来查看内核的运行情况，包括反汇编内核函数。
kgdb：能很方便的在源码级对内核进行调试，缺点是kgdb只能进行远程调试，它需要一根串口线及两台机器来调试内核(也可以是在同一台主机上用vmware软件运行两个操作系统来调试)
printk() 是调试内核代码时最常用的一种技术。在内核代码中的特定位置加入printk() 调试调用，可以直接把所关心的信息打打印到屏幕上，从而可以观察程序的执行路径和所关心的变量、指针等信息。 Linux 内核调试器（Linux kernel debugger，kdb）是 Linux 内核的补丁，它提供了一种在系统能运行时对内核内存和数据结构进行检查的办法。Oops、KDB在文章掌握 Linux 调试技术有详细介绍，大家可以参考。 Kprobes 提供了一个强行进入任何内核例程，并从中断处理器无干扰地收集信息的接口。使用 Kprobes 可以轻松地收集处理器寄存器和全局数据结构等调试信息，而无需对Linux内核频繁编译和启动，具体使用方法，请参考使用 Kprobes 调试内核。
/proc文件系统
在 /proc 文件系统中，对虚拟文件的读写操作是一种与内核通信的手段，要查看内核回环缓冲区中的消息，可以使用 dmesg 工具（或者通过 /proc 本身使用 cat /proc/kmsg 命令）。清单 6 给出了 dmesg 显示的最后几条消息。
清单 6. 查看来自 LKM 的内核输出
[root@plato]# dmesg | tail -5
cs: IO port probe 0xa00-0xaff: clean.
eth0: Link is down
eth0: Link is up, running at 100Mbit half-plex
my_mole_init called. Mole is now loaded.
my_mole_cleanup called. Mole is now unloaded.
可以在内核输出中看到这个模块的消息。现在让我们暂时离开这个简单的例子，来看几个可以用来开发有用 LKM 的内核 API。
调试工具
使用调试器来一步步地跟踪代码，查看变量和计算机寄存器的值。在内核中使用交互式调试器是一个很复杂的问题。内核在它自己的地址空间中运行。许多用户空间下的调试器所提供的常用功能很难用于内核之中，比如断点和单步调试等。
8. 如何在安卓系统上使用arm-linux-gdb调试内核
1，先下载最新版本的gdb源代码包，我使用的是gdb-7.6.tar.gz，使用tar命令进行解包（tar -xvzf gdb-7.6.tar.gz）,cd进gdb-7.6/gdb目录，使用vi找到remote.c中的如下代码:
if(buf_len > 2 * rsa->sizeof_g_packet)
error(_("Remote 'g' packet reply is too long: %s"),rs->buf);
将上面两行注释掉，添加如下代码
if(buf_len > 2 * rsa->sizeof_g_packet)
{
rsa->sizeof_g_packet = buf_len;
for(i = 0; i < gdbarch_num_regs(gdbarch); i++)
{
if(rsa->regs[i].pnum == -1)
continue;
if(rsa->regs[i].offset >= rsa->sizeof_g_packet)
rsa->regs[i].in_g_packet = 0;
else
rsa->regs[i].in_g_packet = 1;
}
}
使用如下命令对代码进行配置、编译和安装
./configure --target=arm-linux --prefix=/usr/local/arm-gdb -v
make
make install
2，gdbserver使用android4.2模拟器中自带的版本（v7.1）
3，将NDK编译好的C/C++可执行程序，上传到模拟器中/data/test目录下，假设可执行程序的名称为testHello。
4，使用命令：gdbserver :7000 /data/test/testHello 启动模拟器端的调试。
5，启动arm-linux-gdb之前，使用vi打开~/.bash_profile文件，在其中添加：
export PATH=$PATH:/usr/local/arm-gdb/bin,以便在程序的其他目录可以直接启动arm-linux-gdb程序
6，cd至ndk编译好的testHello文件所在目录
7，使用如下命令进行端口映射：adb forward tcp:7000 tcp:7000,将模拟器的7000端口和本机的7000端口进行映射
8，使用命令：arm-linux-gdb testHello启动gdb调试
9，使用target remote :7000 链接模拟器中gdbserver启动的服务。
10，自此，我们就可以使用gdb命令进行代码调试了。
9. 嵌入式Linux的GDB远程调试如何实现呢
有道启新嵌入式研究院——远程调试环境由宿主机GDB和目标机调试stub共同构成，两者通过串口或TCP连接。使用GDB标准远程串行协议协同工作，实现对目标机上的系统内核和上层应用的监控和调试功能。调试stub是嵌入式系统中的一段代码，作为宿主机GDB和目标机调试程序间的一个媒介而存在。
就目前而言，嵌入式Linux系统中，主要有三种远程调试方法，分别适用于不同场合的调试工作：用ROM Monitor调试目标机程序、用KGDB调试系统内核和用gdbserver调试用户空间程序。这三种调试方法的区别主要在于，目标机远程调试stub的存在形式的不同，而其设计思路和实现方法则是大致相同的。
而我们最常用的是调试应用程序。就是采用gdb+gdbserver的方式进行调试。在很多情况下，用户需要对一个应用程序进行反复调试，特别是复杂的程序。采用GDB方法调试，由于嵌入式系统资源有限性，一般不能直接在目标系统上进行调试，通常采用gdb+gdbserver的方式进行调试。Gdbserver在目标系统中运行，gdb则在宿主机上运行。
要进行GDB调试，目标系统必须包括gdbserver程序，宿主机也必须安装gdb程序。一般linux发行版中都有一个可以运行的gdb，但开发人员不能直接使用该发行版中的gdb来做远程调试，而要获取gdb的源代码包，针对arm平台作一个简单配置，重新编译得到相应gdb.gdb的源代码包可以从http://ftp.cs.pu.e.tw/Linux/sourceware/gdb/releases/下载，最新版本为gdb-6.4.下载到某个目录，笔者下载到自己的用户目录：/home/vicky.下载完后，进入/home/vicky目录，配置编译步骤如下：
#tar jxvf gdb-6.4-tar-bz2
#cd gdb-6.4
#./configure --target=arm-linux --prefix=/usr/local/arm-gdb -v
#make
(这一步的时候可能会有问题，提示一个函数中（具体函数名不记得了）parse error，就是unsigned前边多了一个”}”,你用vi进入那一行把它删掉就行了。)
#make install
#export PATH=$PATH:/usr/local/arm-gdb
进入gdbserver目录：
#./configure --target=arm-linux –host=arm-linux
#make CC=/usr/local/arm/2.95.3/bin/arm-linux-gcc
(这一步要指定arm-linux-gcc的位置，可能跟你的不一样)
没有错误的话就在gdbserver目录下生成gdbserver可执行文件，把它烧写到flash的根文件系统分区，或通过nfs mount的方式都可以。只要保证gdbserver能在开发板上运行就行。
下面就可以用gdb+gdbserver调试我们开发板上的程序了。在目标板上运行gdbserver，其实就是在宿主机的minicom下，我的red hat linux装在vmware下的。我是在minicom下#mount 192.168.2.100：/ /tmp后做的（这里参数-o nolock可以不加，不加这一步执行得反而更快些），hello和gdbserver都是位于linux根目录下，把主机根目录挂在到开发板的/tmp目录下。
要进行gdb调试，首先要在目标系统上启动gdbserver服务。在gdbserver所在目录下输入命令：
(minicom下)
#cd /tmp
#./gdbserver 192.168.2.100:2345 hello
192.168.2.100为宿主机IP，在目标系统的2345端口开启了一个调试进程，hello为要调试的程序。
出现提示：
Process /tmp/hello created: pid=80
Listening on port 2345
(另一个终端下)
#cd /
#export PATH=$PATH:/usr/local/arm-gdb/bin
#arm-linux-gdb hello
(gdb) target remote 192.168.2.223:2345
（192.168.2.223为开发板IP）
出现提示：
Remote debugging using 192.168.2.223:2345
[New thread 80]
[Switching to thread 80]
0x40002a90 in ??()
同时在minicom下提示：
Remote debugging from host 192.168.2.100
(gdb)
连接成功，这时候就可以输入各种gdb命令如list、run、next、step、break等进行程序调试了。
以上针对通过nfs mount和tftp的方式，只能在主机上调试好后下载到开发板上运行，如果有错误要反复这个过程，繁琐不说，有些程序只能在开发板上调试。所以笔者采用了gdbserver的远程调试方式。希望对大家调试程序有用！