gdb好像没有重新运行程序的命令吧，如果需要重新运行程序，先quit退出gdb，再重新调试不就行了。
② 嵌入式Linux的GDB远程调试如何实现呢
远程调试环境由宿主机GDB和目标机调试
stub共同构成，两者通过串口或TCP连接。使用GDB标准远程串行协议协同工作，实现对目标机上的系统内核和上层应用的监控和调试功能。调试stub
是嵌入式系统中的一段代码，作为宿主机GDB和目标机调试程序间的一个媒介而存在。就目前而言，嵌入式Linux系统中，主要有三种远程调试方法，分别适用于不同场合的调试工作：
用ROM Monitor调试目标机程序
用KGDB调试系统内核
用gdbserver调试用户空间程序。
这三种调试方法的区别主要在于：目标机远程调试stub的存在形式的不同，而其设计思路和实现方法则是大致相同的，而我们最常用的是调试应用程序，就是采用gdb+gdbserver的方式进行调试。在很多情况下，用户需要对一个应用程序进行反复调试，特别是复杂的程序，采用GDB方法调试，由于嵌入式系统资源有限性，一般不能直接在目标系统上进行调试，通常采gdb+gdbserver的方式进行调试。Gdbserver在目标系统中运行，gdb则在宿主机上运行。
下载需要用的的软件包。
一.编译安装arm-linux-gdb
<1>#tar jxvf gdb-7.3.tar.bz2
<2>#cd gdb-7.3
<3>#./configure--target=arm-linux --enable-sim --prefix=/usr/local/bin
<4>#make
<5>#make install
二.编译安装gdbserver
<1>#cd gdb-7.3/gdb/gdbserver
<2>#./configure --target=arm-linux--host=arm-linux
<3>#make
这样在gdb-7.3/gdb/gdbserver目录下就生成了一个gdbserver可执行文件,拷贝到目标开发板上.
三.测试arm-linux-gdb + gdbserver
<1>在超级终端输入：
#./gdbserver 192.168.100.1:2345 hello
[192.168.100.1为pc机ip地址，2345为监听端口，hello为待调试程序
这样在开发板上可以看到如下提示信息：
Process wpa_cli created; pid = 730
Listening on port 2345
表示gdbserver 成功运行等待客户端的连接信息
<2>在pc机上输入：
#arm-linux-gdb hello
然后在GDB界面输入：
#target remote 192.168.100.2:2345
[192.168.100.2为开发板ip地址，2345为开发版监听端口]
这样在开发板上可以看到如下提示信息：
Remote debugging from host 192.168.100.1
表示gdbserver成功运行并且建立连接关系，等待客户端的调试信息。
③ 请教linux下用户态进程调度问题
在进行Linux系统操作的时候，有时候会遇到一次用户态进程死循环，即系统反应迟钝、进程挂死等问题，那么遇到这些问题又该如何解决呢？下面小编就给大家介绍下一次用户态进程死循环的问题该如何处理。
Linux下如何处理一次用户态进程死循环问题
1、问题现象
业务进程（用户态多线程程序）挂死，操作系统反应迟钝，系统日志没有任何异常。从进程的内核态堆栈看，看似所有线程都卡在了内核态的如下堆栈流程中：
［root@vmc116 ~］# cat /proc/27007/task/11825/stack
［《ffffffff8100baf6》］ retint_careful+0x14/0x32
［《ffffffffffffffff》］ 0xffffffffffffffff
2、问题分析
1）内核堆栈分析
从内核堆栈看，所有进程都阻塞在 retint_careful上，这个是中断返回过程中的流程，代码（汇编）如下：
entry_64.S
代码如下：
ret_from_intr：
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
decl PER_CPU_VAR（irq_count）
/* Restore saved previous stack */
popq %rsi
CFI_DEF_CFA rsi，SS+8-RBP /* reg/off reset after def_cfa_expr */
leaq ARGOFFSET-RBP（%rsi）， %rsp
CFI_DEF_CFA_REGISTER rsp
CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET
。。。
retint_careful：
CFI_RESTORE_STATE
bt $TIF_NEED_RESCHED，%edx
jnc retint_signal
TRACE_IRQS_ON
ENABLE_INTERRUPTS（CLBR_NONE）
pushq_cfi %rdi
SCHEDULE_USER
popq_cfi %rdi
GET_THREAD_INFO（%rcx）
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
jmp retint_check
这其实是用户态进程在用户态被中断打断后，从中断返回的流程，结合retint_careful+0x14/0x32，进行反汇编，可以确认阻塞的点其实就在
SCHEDULE_USER
这其实就是调用schele（）进行调度，也就是说当进程走到中断返回的流程中时，发现需要调度（设置了TIF_NEED_RESCHED），于是在这里发生了调度。
有一个疑问：为什么在堆栈中看不到schele（）这一级的栈帧呢？
因为这里是汇编直接调用的，没有进行相关栈帧压栈和上下文保存操作。
2）进行状态信息分析
从top命令结果看，相关线程实际一直处于R状态，CPU几乎完全耗尽，而且绝大部分都消耗在用户态：
［root@vmc116 ~］# top
top - 09:42:23 up 16 days， 2:21， 23 users， load average： 84.08， 84.30， 83.62
Tasks： 1037 total， 85 running， 952 sleeping， 0 stopped， 0 zombie
Cpu（s）： 97.6%us， 2.2%sy， 0.2%ni， 0.0%id， 0.0%wa， 0.0%hi， 0.0%si， 0.0%st
Mem： 32878852k total， 32315464k used， 563388k free， 374152k buffers
Swap： 35110904k total， 38644k used， 35072260k free， 28852536k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27074 root 20 0 5316m 163m 14m R 10.2 0.5 321:06.17 z_itask_templat
27084 root 20 0 5316m 163m 14m R 10.2 0.5 296:23.37 z_itask_templat
27085 root 20 0 5316m 163m 14m R 10.2 0.5 337:57.26 z_itask_templat
27095 root 20 0 5316m 163m 14m R 10.2 0.5 327:31.93 z_itask_templat
27102 root 20 0 5316m 163m 14m R 10.2 0.5 306:49.44 z_itask_templat
27113 root 20 0 5316m 163m 14m R 10.2 0.5 310:47.41 z_itask_templat
25730 root 20 0 5316m 163m 14m R 10.2 0.5 283:03.37 z_itask_templat
30069 root 20 0 5316m 163m 14m R 10.2 0.5 283:49.67 z_itask_templat
13938 root 20 0 5316m 163m 14m R 10.2 0.5 261:24.46 z_itask_templat
16326 root 20 0 5316m 163m 14m R 10.2 0.5 150:24.53 z_itask_templat
6795 root 20 0 5316m 163m 14m R 10.2 0.5 100:26.77 z_itask_templat
27063 root 20 0 5316m 163m 14m R 9.9 0.5 337:18.77 z_itask_templat
27065 root 20 0 5316m 163m 14m R 9.9 0.5 314:24.17 z_itask_templat
27068 root 20 0 5316m 163m 14m R 9.9 0.5 336:32.78 z_itask_templat
27069 root 20 0 5316m 163m 14m R 9.9 0.5 338:55.08 z_itask_templat
27072 root 20 0 5316m 163m 14m R 9.9 0.5 306:46.08 z_itask_templat
27075 root 20 0 5316m 163m 14m R 9.9 0.5 316:49.51 z_itask_templat
。。。
3）进程调度信息
从相关线程的调度信息看：
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15681811525768 129628804592612 3557465
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15682016493013 129630684625241 3557509
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15682843570331 129638127548315 3557686
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15683323640217 129642447477861 3557793
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
15683698477621 129645817640726 3557875
发现相关线程的调度统计一直在增加，说明相关线程一直是在被调度运行的，结合其状态也一直是R，推测很可能在用户态发生了死循环（或者非睡眠死锁）。
这里又有问题：为什么从top看每个线程的CPU占用率只有10%左右，而不是通常看到的死循环进程导致的100%的占用率？
因为线程数很多，而且优先级都一样，根据CFS调度算法，会平均分配时间片，不会让其中一个线程独占CPU。结果为多个线程间轮流调度，消耗掉了所有的cpu。。
另一个问题：为什么这种情况下，内核没有检测到softlockup？
因为业务进程的优先级不高，不会影响watchdog内核线程（最高优先级的实时线程）的调度，所以不会产生softlockup的情况。
再一个问题：为什么每次查看线程堆栈时，总是阻塞在retint_careful，而不是其它地方？
因为这里（中断返回的时候）正是调度的时机点，在其它时间点不能发生调度（不考虑其它情况~），而我们查看线程堆栈的行为，也必须依赖于进程调度，所以我们每次查看堆栈时，正是查看堆栈的进程（cat命令）得到调度的时候，这时正是中断返回的时候，所以正好看到的阻塞点为retint_careful。
4）用户态分析
从上面的分析看，推测应该是用户态发生了死锁。
用户态确认方法：
部署debug信息，然后gdb attach相关进程，确认堆栈，并结合代码逻辑分析。
最终确认该问题确为用户态进程中产生了死循环。
④ 深度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表示八字节
*****************
⑤ 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控制之下。
⑥ linux中如何更改程序的父进程
getppid()
获取父进程
id，
getpid()
获取当前进程
id.
比如
int
main()
{
int
pid
=
fork();
if
(pid
==
0)
{
//
child
printf
("parentid
is
%d\n",
getppid());
}
esle
{
printf("i'm
parent,
id
%d\n",
getpid());
wait(null);
}
return
0;
}
再就是程序编译没错，但是运行时出现“实时专信号
2”
没有源码，谁也帮不上属你。
你可以用
gdb去调试。