ARM系统中, 当crash发生时的back trace调试输出
2011-06-27 21:07
330 查看
在ARM target board上, 如果发生异常,如内存访问越界等情况,有时会非常难debug到底是哪里出错,近来看了一下back trace回溯的功能及实现,在这里做个笔记。
首先,back trace要涉及到一堆寄存器, 不过不用担心, 实际上没你想象的那么难。
在linux kernel的代码中可以看到关于ARM寄存器的定义,在这里列一下:
linux/include/asm-arm/proc-armv/ptrace.h
struct pt_regs ...{
long uregs[18];
};
#define ARM_cpsr uregs[16] //当前程序状态寄存器
#define ARM_pc uregs[15] //程序计数器 指令计数器,下一条将要执行的指令
#define ARM_lr uregs[14] //链接link寄存器,是退出时要装载到pc中的值,返回回来时就是到这个里面去执行之前的代码
#define ARM_sp uregs[13] //栈指针
#define ARM_ip uregs[12] //指令指针,指向下一指令
#define ARM_fp uregs[11] //帧指针
#define ARM_r10 uregs[10]
#define ARM_r9 uregs[9]
#define ARM_r8 uregs[8]
#define ARM_r7 uregs[7]
#define ARM_r6 uregs[6]
#define ARM_r5 uregs[5]
#define ARM_r4 uregs[4]
#define ARM_r3 uregs[3]
#define ARM_r2 uregs[2]
#define ARM_r1 uregs[1]
#define ARM_r0 uregs[0]
#define ARM_ORIG_r0 uregs[17]
这里比较重要的几个寄存器是fp,lr,sp,继续往后讨论。
我们可以先想象一个情景,某个调用过程
A(…)
{
…;
B(…);
printf("aaa ");
}
在A调B的时候,大体的过程会是A在执行,执行到B,进入B执行,B执行完后,在A中的B下面的部分继续执行。
这样的话,在转到B去执行的时候,要准备好一些东西,来保证B完成时还回到A里来继续往下执行。
怎么来保证上面的这个问题呢,那就是要用到lr寄存器来存A处的信息,这个是link register链接寄存器的缩写,它就好比一个链条一样,把一堆调用给串起来。
所以上面的过程就会是,要执行到B时,把B的地址放入pc中,这样下面就要执行B了。Pc是指令计数器,放在其中的地址就将被执行。这个时候还要保存刚才我们提到的A的信息,把需要返回的值放在lr中。
在ARM的过程调用中,有个结构叫回溯结构,还有两个概念叫帧和栈,它们的关系是:
回溯结构
|-----------|------------------------------| 帧
栈 … 帧
… 帧
回溯结构在帧的高端,通过这个回溯结构,就可以把一个一个的帧连接成栈。
帧指针fp,frame pointer就是指向把栈给串起来的一个一个回溯结构所组成的列表中的最后一个结构。这样就可以通过这个fp来追溯函数的调用顺序,在系统崩溃时就可以得到最后调用的函数都是哪些。
回溯结构是:
高地址
保存代码指针 [fp] fp指向这里
返回lr值 [fp, #-4]
返回sp值 [fp, #-8]
返回fp值 [fp, #-12] 指向下一个结构
…
低地址
从上面的内容,我们只要循环打印上面lr中的值就可以得到我们想要的一系列的地址了。
long fp, nextfp;
fp = regs->ARM_fp;
long lr;
for(XXX;XXX;XXX) //循环多少,可以自己决定
...{
lr = *(( long *)(fp - 4));
nextfp = *(( long *) fp - 12));
fp = nextfp;
printk(“call address: 0x%lx ”, lr- current->mm->start_code - 4);
}
上面的current->mm->start_code是当前进程的数据段基地址,再减4,就能得到返回处前面的地址。打印出来的内容也就是调用函数的地址。
如:
call address: 0x2849cc
call address: 0x3b8b70
call address: 0x2c270
call address: 0x2c5ec
call address: 0x2b298
call address: 0x283934
call address: 0x3c41a8
你可以用objdump得到你的执行文件的sym文件,如:
arm-elf-objdump -SD test.gdb > /tmp/test.gdb.sym
然后就可以拿这个循环打印出来的地址,来搜索出错的位置了。
上面的代码只是一个参考,具体还要看你的系统实际的情况。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/mimepp/archive/2007/08/08/1732938.aspx
首先,back trace要涉及到一堆寄存器, 不过不用担心, 实际上没你想象的那么难。
在linux kernel的代码中可以看到关于ARM寄存器的定义,在这里列一下:
linux/include/asm-arm/proc-armv/ptrace.h
struct pt_regs ...{
long uregs[18];
};
#define ARM_cpsr uregs[16] //当前程序状态寄存器
#define ARM_pc uregs[15] //程序计数器 指令计数器,下一条将要执行的指令
#define ARM_lr uregs[14] //链接link寄存器,是退出时要装载到pc中的值,返回回来时就是到这个里面去执行之前的代码
#define ARM_sp uregs[13] //栈指针
#define ARM_ip uregs[12] //指令指针,指向下一指令
#define ARM_fp uregs[11] //帧指针
#define ARM_r10 uregs[10]
#define ARM_r9 uregs[9]
#define ARM_r8 uregs[8]
#define ARM_r7 uregs[7]
#define ARM_r6 uregs[6]
#define ARM_r5 uregs[5]
#define ARM_r4 uregs[4]
#define ARM_r3 uregs[3]
#define ARM_r2 uregs[2]
#define ARM_r1 uregs[1]
#define ARM_r0 uregs[0]
#define ARM_ORIG_r0 uregs[17]
这里比较重要的几个寄存器是fp,lr,sp,继续往后讨论。
我们可以先想象一个情景,某个调用过程
A(…)
{
…;
B(…);
printf("aaa ");
}
在A调B的时候,大体的过程会是A在执行,执行到B,进入B执行,B执行完后,在A中的B下面的部分继续执行。
这样的话,在转到B去执行的时候,要准备好一些东西,来保证B完成时还回到A里来继续往下执行。
怎么来保证上面的这个问题呢,那就是要用到lr寄存器来存A处的信息,这个是link register链接寄存器的缩写,它就好比一个链条一样,把一堆调用给串起来。
所以上面的过程就会是,要执行到B时,把B的地址放入pc中,这样下面就要执行B了。Pc是指令计数器,放在其中的地址就将被执行。这个时候还要保存刚才我们提到的A的信息,把需要返回的值放在lr中。
在ARM的过程调用中,有个结构叫回溯结构,还有两个概念叫帧和栈,它们的关系是:
回溯结构
|-----------|------------------------------| 帧
栈 … 帧
… 帧
回溯结构在帧的高端,通过这个回溯结构,就可以把一个一个的帧连接成栈。
帧指针fp,frame pointer就是指向把栈给串起来的一个一个回溯结构所组成的列表中的最后一个结构。这样就可以通过这个fp来追溯函数的调用顺序,在系统崩溃时就可以得到最后调用的函数都是哪些。
回溯结构是:
高地址
保存代码指针 [fp] fp指向这里
返回lr值 [fp, #-4]
返回sp值 [fp, #-8]
返回fp值 [fp, #-12] 指向下一个结构
…
低地址
从上面的内容,我们只要循环打印上面lr中的值就可以得到我们想要的一系列的地址了。
long fp, nextfp;
fp = regs->ARM_fp;
long lr;
for(XXX;XXX;XXX) //循环多少,可以自己决定
...{
lr = *(( long *)(fp - 4));
nextfp = *(( long *) fp - 12));
fp = nextfp;
printk(“call address: 0x%lx ”, lr- current->mm->start_code - 4);
}
上面的current->mm->start_code是当前进程的数据段基地址,再减4,就能得到返回处前面的地址。打印出来的内容也就是调用函数的地址。
如:
call address: 0x2849cc
call address: 0x3b8b70
call address: 0x2c270
call address: 0x2c5ec
call address: 0x2b298
call address: 0x283934
call address: 0x3c41a8
你可以用objdump得到你的执行文件的sym文件,如:
arm-elf-objdump -SD test.gdb > /tmp/test.gdb.sym
然后就可以拿这个循环打印出来的地址,来搜索出错的位置了。
上面的代码只是一个参考,具体还要看你的系统实际的情况。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/mimepp/archive/2007/08/08/1732938.aspx
相关文章推荐
- ARM系统中, 当crash发生时的back trace调试输出
- 通达OA PHP开发环境设置系统输出调试信息
- 通达OA PHP开发环境设置系统输出调试信息
- 用GDB动态打印快速实现嵌入式系统的调试输出
- windows下eclipse cdt 无法运行和调试程序,没有输出(调试和运行时不修改系统变量导入第三方dll库)
- UT-Exynos4412开发板三星ARM四核旗舰开发平台android4.0体验-12音频输入输出功能调试
- 嵌入式成长轨迹33 【嵌入式学习阶段】【ARM环境调试】【在虚拟机下Ubuntu建立NFS网络文件系统】
- kernel启动控制台还不可用时发生crash的调试方法
- stm32系统在线调试时程序运行正常输出正常,但是一旦把程序烧写进去则输出不正常
- kernel启动console_init之前console不可用时发生crash的调试方法
- stm32系统在线调试时程序运行正常输出正常,但是一旦把程序烧写进去则输出不正常
- LINUX系统的调试信息是如何从串口输出的
- ARM系统设计笔记4--调试技巧
- Xcode8屏蔽系统bug,真机调试NSLog没输出
- ARM2440学习笔记--Linux系统下串口调试和USB调试环境搭建
- 停用 iOS 模拟器输出大量的系统调试数据
- 系统中调试信息的输出
- 高通平台采用gpu-mmu的时候发生显存耗完而整个系统内存尚有的情况导致crash和重启
- Windows和Linux系统的Debug调试信息输出方法
- 通过CPU串口输出调试DSP系统