引言
不管在PC端还是在嵌入式设备中，代码执行过程中运行出错，如栈溢出，引用野指针，重复free同一块内存等等，都是件非常可怕的事情。好在PC端操作系统会帮我们终止相关进程，并回收其资源，不至于导致整个操作系统崩溃。 而嵌入式设备就比较惨了，往往会导致系统宕机，直接重启，很大程度影响了我们产品的可靠性。 同时随着工程代码越来越庞大， 出现宕机的原因也难以具体分析出到底是哪一行导致的系统崩溃。今天我们就来介绍一个神器，即如何使用addr2line命令来跟踪代码运行出错时，具体是哪行代码导致的，以帮助我们定位问题所在。
addr2line是什么东东
addr2line 工具（它是标准的 GNU Binutils 中的一部分）是一个可以将指令的地址和可执行映像转换成文件名、函数名和源代码行数的工具。通俗来讲就是可以根据宕机时PC(程序计数器)的值来转化为具体执行了哪个文件下的函数中的代码(行号）。这里说的是esp8266和esp32采用xtensa交叉编译工具链，集成了Binutils中的工具集，如addr2line， ar，as，ld等等。它们分别在xtensa-lx106-elf\bin(esp8266)，xtensa-esp32-elf\bin(esp32)目录中。
在linux中使用addr2line工具
既然知道了addr2line是GNU Binutils中的一个工具，那么我们就先在linux中尝尝鲜，看看addr2line是如何使用的吧。 这里我们简单编写一个简单的例子：定义一个int *指针，并初始化为NULL， 然后解引用，即赋值为0，具体如下：
//测试源文件test.c
#include <stdio.h>
int main(void)
{
int *p = NULL;
*p = 0;
return 0;
} 然后我们尝试编译，这里需要注意的是，要加-g选项，意思是在生成可执行文件中添加调试信息，否则之后是无法使用addr2line来定位问题的，这是因为addr2line的是依赖于调式信息来跟踪的。具体编译指令：
gcc -g test.c -o test可以看到编译无错误无警告，接着我们尝试运行下：
运行出现段错误，相信原因大家都应该很清楚吧， 解引用一个为NULL的指针。
好了，接下来就是我们的主角addr2line大显神威的时候拉~
首先我们知道addr2line是基于PC(程序计算器)来定位的，因此我们就得知道出现段错误时，那时PC的值是多少，这里我们使用命令：
dmesg | grep test简单介绍下上面命令的含义：
- dmesg命令是linux中显示系统日志，即会记录系统从开机到运行的一些重要信息，其中就会包含上面我们运行出错的记录信息。
- 符号 ‘|’ ， 是管道的意思，所谓管道就是将前面(|的左边，如dmesg)的执行结果作为后面(|后面，如grep test)的输入
- grep，是linux中非常强大的命令，可以查询文件中内容
综合以上含义，这条命令就是在系统日志中查询含有test(我们生成的可执行文件名)的内容，避免是在大量日志中繁琐的查找，直接定位。当然不嫌麻烦的小伙伴的，可以直接使用dmesg命令，然后自己手动去找，也是可以的哦~
注：上面显示的结果中有多出test记录，这是因为我之前测试不同的代码导致的，最后一个才是我最后执行出错的记录， 我们可以看到此时ip为‘00000000004004e6’
最后使用addr2line工具定位问题代码行，具体指令：
addr2line -e test 00000000004004e6其中-e选项是用来指定要定位问题的可执行文件， 最后面00000000004004e6就是PC(ip)的值
从结果我们看到，addr2line工具帮我们定位到问题：在test.c的第8行代码，即*p = 0; 跟我们预想的一致，由于我们测试源文件比较简单，大家在测试的时候可以将测试代码写的复杂点哦~
esp8266/esp32 使用addr2line工具
esp8266和esp32作为目前物联网最热门的一块wifi芯片之一， 相信大家在开发过程中会遇到各种各样的问题。 而最让人头疼，摸不着头脑的就是系统崩溃重启，尤其没有经验的小伙伴根本不知道如何查找问题的根源，刚好原厂乐鑫提供的编译工具链中就有addr2line工具，给我们带来了极大便利。
这里以esp32为例子，以下是在实际工程中，在应用主函数app_main中简单实现了解引用NULL指针p，即赋值为0：
接着编译运行，串口输出：
可以看到系统崩溃了，打印了出一些信息： 如
Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled
其中StoreProhibited 粗略的告知我们是关于存储错误导致的，并打印了系统崩溃时，一些寄存器的值，而我们最关心的就是当前PC(程序计数器)的值， 上图中PC的值显示： 0x400e4235， 以及下方
Backtrace: 0x400e4235:0x3ffb4cf0 (这里需要说明的是esp8266和esp32是双核cpu，因此有2个PC程序计数器)， 这里我们根据提示是核心core0崩溃的，对应的PC就是0x400e4235。OK，接下来我们就利用addr2line来定位出问题的代码：
首先我们cd到编译生成的buile文件夹中：
然后输入命令：
xtensa-esp32-elf-addr2line -e project-DD7002B.elf 0x400e4235Enter回车：
可以看到输出显示出问题的代码所在的详细路径 和 行号，即在Test_Hub.c的第55行代码导致的系统崩溃，之后大家就可以以此为突破口来分析问题了。
总结
addr2line工具虽然能够帮助我们定位问题代码的路径和行号，但是不是所有的环境都支持该功能，因此大家在实际开发过程应当有自我意识，自己所写的每一行代码做到心中有数，尤其是在内存，指针等操作。 这就离不开平时的不断学习，提高自己的编程能力。
