1. 需要在代码中加入,并编译
2.烧录代码运行后看到错误打印如下
3.在刚刚烧录的文件对应的hunter.debug和hunter文件,执行如下操作 ,得出反汇编文件hunter1_elf
zhanbb@hamedal:~/D40/0908/d40$ cd ~/D40/0908/d40/packshop/Trunk/Proj/Bin
zhanbb@hamedal:~/D40/0908/d40/packshop/Trunk/Proj/Bin$ ls
hunter hunter.debug hunter_elf
zhanbb@hamedal:~/D40/0908/d40/packshop/Trunk/Proj/Bin$
zhanbb@hamedal:~/D40/0908/d40/packshop/Trunk/Proj/Bin$
zhanbb@hamedal:~/D40/0908/d40/packshop/Trunk/Proj/Bin$
zhanbb@hamedal:~/D40/0908/d40/packshop/Trunk/Proj/Bin$ /opt/rockchip-linux/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-objdump -D hunter.debug
> hunter1_elf
zhanbb@hamedal:~/D40/0908/d40/packshop/Trunk/Proj/Bin$ ls
hunter hunter1_elf hunter.debug hunter_elf
然后反汇编文件中通过地址可以找出相应的函数,这里可以看出是失败了,没有找出,正常是会有找出的
当然也可以在服务器通过指令
cd ~/D40/0908/d40/packshop/Trunk/Proj/Bin
addr2line -e hunter.debug 0x40b180
来定位具体问题出在哪个函数
后期总结:看来伟东山老师的单片机开发过程中的2个调试绝招有感悟,发现这个使用print_backtrace方法应该是可行的,具体为什么打印出来的堆栈信息不对,应该是注册信号处理函数的地方不对,还有就是当时应该根据他给的错误的堆栈地址,其看反汇编文件,通过反汇编文件一步一步看调用的函数关系来找到问题在哪,同时看不懂反汇编文件没事,可以让gpt分析。