起因

Addr2line 工具（它是标准的 GNU Binutils 中的一部分）是一个可以将指令的地址和可执行映像转换成文件名、函数名和源代码行数的工具。这种功能对于将跟踪地址转换成更有意义的内容来说简直是太棒了。

要了解这个过程是怎样工作的，我们可以试验一个简单的交互式的例子。（我直接从 shell 中进行操作，因为这是最简单地展示这个过程的方法，如清单 4 所示。）这个示例 C 文件（test.c）是通过 cat 一个简单的应用程序实现的（也就是说，将标准输出的文本重定向到一个文件中）。

然后使用 gcc 来编译这个文件，它会传递一些特殊的选项。首先，要（使用 -Wl 选项）通知链接器生成一个映像文件，并（使用 -g 选项）通知编译器生成调试符号。最终生成可执行文件 test。

得到新的可执行应用程序之后，您就可以使用grep 工具在映像文件中查找 main 来寻找它的地址了。使用这个地址和 Addr2line 工具，就可以判断出函数名（main）、源文件（/home/grabbyte/test/test.c）以及它在源文件中的行号（4）。

在调用 Addr2line 工具时，要使用 -e 选项来指定可执行映像是 test。通过使用 -f 选项，可以告诉工具输出函数名。

技术实现原理

为什么一个地址能反查出函数名和行号

编译链接时，ELF 文件里留下了两类“翻译资料”：

符号表（.symtab）：链接器给每个函数、变量分配了最终地址，符号表记录“这个名字住在哪个地址、占多大地方”；
调试信息（-g 生成的 DWARF 调试段）：把源码的每一行映射到地址区间。

addr2line 做的事就是反查这张表：拿地址先在符号表里找到包含它的函数，再到行表里找到覆盖它的源码行。前提是这些段还在——所以编译要带 -g，文件不能被 strip。

崩溃日志里的 pc 值为什么能直接用

程序运行时的指令地址 = 加载基址 + 模块内偏移。tombstone 这类崩溃日志为了摆脱加载地址的随机性，打印的 #01 pc 00026cb3 /system/bin/newcdr 里 pc 是相对模块的偏移；而 addr2line 查询用的正是 ELF 里记录的静态地址（相当于基址为 0 时的偏移）。两边口径一致，所以把日志里的偏移直接喂给 addr2line 就行，不需要知道程序当时被加载到了哪里。

顺带解释日志里的 android::RefBase::incStrong(void const*) const+1：+1 表示 pc 落在符号入口之后 1 字节处（ARM 平台这一位同时是 Thumb/ARM 指令集标志去掉后的效果）。符号解析不出来时就只剩光秃秃的地址——这正是需要 addr2line 的地方。

常用参数

-e 文件：指定被查询的 ELF（可执行程序或 so）；
-f：同时输出函数名，不加就只有“文件名:行号”；
-C：C++ 名字 demangle，把 _ZN10EventManager4initEb 这种修饰名还原成 EventManager::init(bool)；
-i：把内联展开的整条调用链都列出来，优化版固件定位时很有用。

实战：全志A20平台

下面在全志A20平台介绍使用addr2line命令使用方法

1.打开调试宏

将下面红色部分的return NULL屏蔽

1
2
3
4
5
6
7
8


#define TOMBSTONE_DIR   "/mnt/extsd/tombstones"

char* engrave_tombstone(pid_t pid, pid_t tid, int signal,
        bool dump_sibling_threads, bool quiet, bool* detach_failed,
        int* total_sleep_time_usec) {undefined
//return NULL;//ignore request tombstone. by yangy.
    mkdir(TOMBSTONE_DIR, 0755);
    chown(TOMBSTONE_DIR, AID_SYSTEM, AID_SYSTEM);

2.之后出现的段错误将会在TF卡中的tombstones文件夹中保存

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'unknown'
Revision: '0'
pid: 907, tid: 966, name: InitStage2  >>> /system/bin/newcdr <<<
signal 6 (SIGABRT), code -6 (?), fault addr --------
    r0 81f2a668  r1 40f8b814  r2 40f95330  r3 3ab0a84b
    r4 40f8b808  r5 40f95338  r6 40f8b814  r7 00000000
    r8 40f8b80c  r9 00100000  sl 40f87750  fp 00000000
    ip 4012fba4  sp 412addd0  lr 40121cb7  pc 40229b70  cpsr 90000030
    d0  6c6576656c207974  d1  65726854726f7365
    d2  00000000656c6174  d3  3d1ce80a6f726553
    d4  3ce6000002000000  d5  646e61203d1ce80a
    d6  7220657669726420  d7  0000000073696765
    d8  0000000000000000  d9  0000000000000000
    d10 0000000000000000  d11 0000000000000000
    d12 0000000000000000  d13 0000000000000000
    d14 0000000000000000  d15 0000000000000000
    d16 3f686a0000000000  d17 3fc99999a0000000
    d18 3fdfffffffbcdc80  d19 3fe0000000000000
    d20 3fe00000002191c0  d21 be0835142e800000
    d22 bf701acdbb94a830  d23 bf66c16b8a684294
    d24 3fc55554f93c9426  d25 3fefdfdfdfdfdfe0
    d26 3fd55559bbdd3a9f  d27 3fdb6dbc40ea66d3
    d28 3fe33336ab4b34f0  d29 bf70101010101000
    d30 3fffefef00000000  d31 0000000000000000
    scr 20000010

backtrace:
    #00  pc 0000cb70  /system/lib/libutils.so (android::RefBase::incStrong(void const*) const+1)
    #01  pc 00026cb3  /system/bin/newcdr

stack:
         412add90  404ac2ac  
         412add94  00000000  
         412add98  4012b956  /system/bin/newcdr
         412add9c  404ac29c  
         412adda0  00000000  
         412adda4  40f8b808  
         412adda8  4022bd9d  /system/lib/libutils.so (android::Thread::run(char const*, int, unsigned int))
         412addac  40f8b814  
         412addb0  00000000  
         412addb4  40f8b80c  
         412addb8  00100000  
         412addbc  3ab0a84b  
         412addc0  40f8b808  
         412addc4  40f95338  
         412addc8  df0027ad  
         412addcc  00000000  
    #00  412addd0  40f8b808  
         412addd4  40121cb7  /system/bin/newcdr
    #01  412addd8  40f8b808  
         412adddc  40f87be0  
         412adde0  404ae560  
         412adde4  40f8b808  
         412adde8  401dc228  
         412addec  00000000  
         412addf0  4022b99d  /system/lib/libutils.so
         412addf4  4010d8d7  /system/bin/newcdr
         412addf8  00000000  
         412addfc  00000000  
         412ade00  00000000  
         412ade04  00000000  
         412ade08  00000000  
         412ade0c  01000000  
         412ade10  00000001  
         412ade14  00000000  

3.进到bin目录

使用addr2line -C -f -e newcdr 00026cb3命令查看出错位置

1
2
3


grabbyte@tfsrv01:~/system/bin$ addr2line -C -f -e  newcdr 00026cb3
EventManager::init(bool)
/home/grabbyte/newcdr/src/event/EventManager.cpp:338

结果怎么读

addr2line -C -f -e newcdr 00026cb3 输出两行：第一行函数名，第二行 文件:行号，直接定位到 EventManager.cpp:338。把 backtrace 里每个“pc 偏移 / 所在模块”逐条这样翻译，整条崩溃调用链就还原成了源码位置。

当然我们自己写带c/c++段错误也可以用这个工具来调试

踩坑记录与注意事项

必须用“崩溃的那个版本”的带符号文件：重新编译过一次，函数地址就全变了，查出来的是张冠李戴的行号——而且它看起来完全合法，比查不出来更害人；
strip 过的文件只能查导出符号：.symtab 被 strip 后只剩 .dynsym，静态函数、C++ 内部方法都查不到；
优化让行号“漂移”：-O2 下指令重排、内联，行号经常指向函数开头或下一行，只能当参考区间，配合 -i 看内联链；
查 so 用 so 自己做 -e：可执行文件的符号表里没有动态库里函数的地址，各模块要各自查；
喂的永远是模块内偏移：如果手头只有绝对运行地址，先减去该模块当时的加载基址（/proc//maps 或日志里的加载地址）再查；
行号是 0 或 ??：地址落在符号间填充区、PLT，或调试信息没覆盖（汇编源文件、预编译库），属正常现象，查相邻帧即可。

用 Addr2line 可以将函数地址解析为函数名

Contents

起因