ELF符号表解析：从运行地址反查函数名的原理与工具实践

做Linux服务端或者嵌入式开发的兄弟，一定见过这种日志——程序崩了，回栈里全是十六进制地址，比如0x5567a2f1c34b。这时候最想干的一件事，就是从ELF文件里把这串运行地址翻译成具体的函数名，搞清楚到底崩在哪。这个需求太常见了：crash分析、perf性能剖析、线上监控报文解析，全都离不开“运行地址 -> 函数名”这条映射链路。工具链里有现成的addr2line，原理也完全可以自己写一个解析器，弄明白符号表之后，再看到一堆地址心里就有底了。

这套东西适合谁学？凡是手上拿着ELF文件（可执行文件、共享库、内核模块）又需要定位问题的，不管是搞Linux后端、Android native、嵌入式，还是做安全研究，都属于基本功。文章分成几块：先说场景和概念，再拆ELF符号表结构，接着给现成工具的操作方法，最后写一个能从零解析的自制脚本，顺带把常见坑都踩一遍。

1. 为什么“地址反查函数名”是刚需

1.1 那些天书一样的崩溃栈

先还原一个真实画面。服务端程序崩溃后，日志里常见的backtrace长这样：

#01 pc 0x0000000000007a34 /usr/lib/libfoo.so.1 #02 pc 0x0000000000001234 /usr/bin/myapp #03 pc 0x00007f8a2c1d56e0 /usr/lib/libc.so.6

如果你手头没有symbol文件，这几行基本等于废话，唯一的结论就是“它崩了”。可一旦能把这几个地址映射成函数名，信息量立刻爆炸：libfoo.so.1的0x7a34是FooBar::Init()里的一行代码，myapp的0x1234是main()调用FooBar::Init()的位置，整个调用链瞬间变成可读的黑盒回放。

这背后依赖的就是ELF文件里的符号表和调试信息。每个函数在编译链接时都会生成一个符号项，记录它的名字、类型、大小和地址。反查的本质就是拿运行地址去符号表里做一次区间匹配，命中哪个函数的地址范围，就能确定它在哪个函数里。

1.2 两种地址形态：虚拟地址与装载偏移

很多新手卡在“运行地址”这个概念上。注意，日志里的地址并不是ELF文件里的原始地址，两者之间可能差了一个“加载基址”。

• 对于普通的非PIE可执行文件（ET_EXEC），链接器把地址固定在某个值附近，符号表里的st_value基本就是运行时地址，直接用。
• 对于PIE程序和共享库（ET_DYN），符号表里的st_value是相对基址的偏移量。程序运行时会被加载到任意地址，真实地址 = 加载基址 + 偏移量。

拿/proc/<pid>/maps一看就明白，里面每一行形如7f8a2c1d0000-7f8a2c3d0000 r-xp /usr/lib/libc.so.6，前面的区间起点就是这个库的加载基址。日志里的pc 0x7f8a2c1d56e0减去基址 0x7f8a2c1d0000，得到偏移0x56e0，再去符号表里查0x56e0，这才是正确姿势。

我们平时说的“由运行地址定位函数名”，核心就是在做两步：先减基址（如果必要），再拿偏移去符号表匹配。很多线上遇到“地址对不上”“查不到符号”的问题，一半都是差了这个基址。

1.3 需要这套能力的场景不止崩溃

除了惊心动魄的crash回栈，性能剖析也一样。perf record采样到的都是一条条指令地址，perf report要把它们归并到函数上才能展示热点占比。没有符号表，perf 只能显示 “unknown”。再比如内存泄漏监控，采集到的调用栈是地址数组，服务端解析时就要用同样的映射逻辑。还有系统调用跟踪、运行时动态插桩、反调试对抗研究——凡是一个地址落在代码段里并且你想知道它属于谁，都需要这个能力。

2. ELF符号表：藏在文件里的活地图

2.1 符号表到底长什么样

先别急着用工具，把底层的符号表结构看明白，后面不管是排错还是写脚本都稳。

ELF文件结构像一个多层抽屉：开头是ELF头（ELF Header），里面记录了“抽屉柜”的位置信息。其中e_shoff字段指向节头表（Section Header Table）的偏移，节头表是一组描述各个节（Section）的元数据。每个节有名字、类型、地址、大小等属性。符号表就是一个特定类型的节，通常叫.symtab（完整符号表，链接/调试用）或.dynsym（动态符号表，运行时动态链接用）。

64位ELF的符号项结构固定24字节：

st_info这个字节要拆开看，低4位表示类型，高4位表示绑定。最常见类型是STT_FUNC（值2，表示函数）和STT_OBJECT（值1，表示全局变量）。绑定属性有STB_GLOBAL（全局）、STB_LOCAL（局部）、STB_WEAK（弱符号）。readelf -s输出的那几列Num: Value Size Type Bind Vis Ndx Name，就是从这些字段直接解出来的。

比如一个典型的函数符号：

12: 0000000000007a20 260 FUNC GLOBAL DEFAULT 13 FooBar::Init()

意思是FooBar::Init()这个函数，从地址偏移0x7a20开始，占260字节。那么运行地址0x7a34落在这个区间里，自然就能反推出属于它。

2.2 符号名与节表的关系

符号项本身只存“名字在字符串表里的偏移”，也就是一个整数，字符串真正内容放在.strtab（和.symtab配对）或.dynstr（和.dynsym配对）里。这种间接引用在二进制格式里很常见，好处是字符串不重复存储、符号项定长紧凑。

解析时的套路是：先在节头表里找到符号表节和它对应的字符串表节，然后遍历符号项；对每个符号，用st_name作为偏移在字符串表里取以\0结尾的字符串。注意节头表里每个节有一个sh_link字段，对于符号表，sh_link就指向配对的字符串表节索引。自己写解析器时一定要读这个字段，而不是硬编码节索引，因为不同ELF文件的节排列顺序不一样。

值得注意的是，.symtab通常在运行时并不加载进进程内存，它只存在于文件里，链器用来做符号决议和重定位；真正加载的是.dynsym，它是动态链接器工作时使用的“精简版”符号表。这解释了为什么有些库strip掉.symtab后仍能运行，但要调试就恼火了。

2.3 类型不只是函数：为什么不能只查STT_FUNC

反查函数名最容易忽略的点是：一个ELF里除了函数符号，还有变量符号、节符号、文件符号、甚至没类型的STT_NOTYPE。我们建立索引时要留个心眼：

• 用st_value和st_size匹配函数区间，最可靠的是筛选STT_FUNC；
• 有些汇编裸写的函数类型可能是STT_NOTYPE，地址对上了也不能漏掉；
• 全局变量如果正好落在地址区间里，也要能区分出来，否则把变量当函数名报上去会误导人。

在我自己的解析器里，我会把STT_FUNC和STT_NOTYPE都收集，但给不同类型打上标签，查询的时候优先展示函数类型。这只是工程上的取舍，没有绝对标准。

3. 先拿现成工具练手：addr2line、nm、readelf

3.1 addr2line：一条命令解决90%的问题

如果目标机器上装了binutils，反查函数名最省事的工具就是addr2line：

addr2line -f -C -e /usr/lib/libfoo.so.1 0x7a34

参数含义很好记：-f显示函数名，-C把C++的修饰名转成可读的FooBar::Init()，-e指定ELF文件。如果这个文件带调试信息（编译时加了-g），输出还能带上文件名和行号：

FooBar::Init() /home/dev/foo/src/foobar.cpp:128

这行输出对排查问题基本就是“银弹”了——不只是函数名，连第几行都出来了。

没有调试信息也不怕，符号表还在的话，-f依然能给出函数名，只是行号部分会显示??。这时候函数边界没有行级信息那么精确，但定位到函数级别已经足够判断方向。

3.2 nm和readelf：没有debug信息时的替补方案

nm是最传统的符号查看器，按地址排序功能尤其实用：

nm -n /usr/lib/libfoo.so.1 | grep -i foo

输出里0000000000007a20 T _ZN6FooBar3InitEv，T表示代码段全局符号（t是小写，表示局部符号）。地址列是按升序排的，肉眼扫一眼就能看出目标地址落在哪个区间。

readelf -s则更接近原始数据：

readelf -sW /usr/lib/libfoo.so.1 | grep '7a20\|7a34'

输出列完整展示了Value Size Type Bind Vis Ndx Name，很多脚本化处理时直接解析它的列比调addr2line还快。-W参数防止输出被截断，老版本注意加。

用nm的方式查函数名有个技巧：先nm -n拿到地址排序后的符号列表，再找一个地址刚好小于等于目标地址的符号，看它是否落入这个符号的size区间。实现背后就是二分查找，下节我自己写的脚本也是这个思路。

3.3 C++符号修饰与demangle

_ZN6FooBar3InitEv这种东西初看像乱码，其实是Itanium C++ ABI的修饰名。里面编码了命名空间、类名、函数名、参数类型。上面这个串拆开就是_Z N 6FooBar 3Init E v，即FooBar::Init()，参数为空。

用addr2line -C或者c++filt都能还原成人话。如果自己写解析器，建议用一个成熟的demangle库，不要手写解析修饰规则的解析器，那是个大坑。Python可以用pyelftools配合libcxx或者调用c++filt子进程；C/C++可以用 abi::__cxa_demangle。这一点决定你的工具能不能在C++项目实战中用起来。

4. 自己写一个地址解析器

4.1 从ELF头到节头表：自己动手的第一步

工具虽好，但有时候需要批量处理、离线分析、自定义输出，还是得自己写解析。Python是搞这类分析最快的方式。我们来拆一个最小可用的ELF解析器，以64位ELF为例，32位的逻辑完全相同，只是字段宽度减半。

ELF头开头16字节是魔数和类别，其中第4字节标明是32（1）还是64位（2）。64位ELF里e_shoff在偏移0x28处占8字节，e_shentsize在0x3A处占2字节，e_shnum在0x3C处占2字节，e_shstrndx在0x3E处占2字节。节头表项每个64字节，字段依次为：sh_name（4字节）、sh_type（4）、sh_flags（8）、sh_addr（8）、sh_offset（8）、sh_size（8）、sh_link（4）、sh_info（4）、sh_addralign（8）、sh_entsize（8）。

有了节头表，就能根据sh_type找到SHT_SYMTAB（值2）和SHT_DYNSYM（值11）的节。然后从sh_offset处读符号项，每个24字节。

import struct def read_elf_symbols(path): with open(path, 'rb') as f: data = f.read() if data[:4] != b'\x7fELF': raise ValueError('not an ELF file') is64 = data[4] == 2 if is64: e_shoff = struct.unpack_from('<Q', data, 0x28)[0] e_shentsize = struct.unpack_from('<H', data, 0x3A)[0] e_shnum = struct.unpack_from('<H', data, 0x3C)[0] e_shstrndx = struct.unpack_from('<H', data, 0x3E)[0] sym_size = 24 sym_fmt = '<IBBHQQ' else: e_shoff = struct.unpack_from('<I', data, 0x20)[0] e_shentsize = struct.unpack_from('<H', data, 0x2E)[0] e_shnum = struct.unpack_from('<H', data, 0x30)[0] e_shstrndx = struct.unpack_from('<H', data, 0x32)[0] sym_size = 16 sym_fmt = '<IBBHII' shdrs = [] for i in range(e_shnum): off = e_shoff + i * e_shentsize shdrs.append(struct.unpack_from('<IIQQQQIIQQ', data, off) if is64 else struct.unpack_from('<IIIIIIIIII', data, off)) ...

顺手解释一下这几个unpack格式：<表示小端，IBBHQQ对应uint32, uint8, uint8, uint16, uint64, uint64，正好24字节。64位用QQ匹配st_value和st_size，32位对应II。工程上不能写死大小端，但从ELF头e_ident[5]可以判断字节序（1为小端，2为大端），这里默认小端只是为了读主流平台的文件，真实工具里最好还是做个分支。

4.2 遍历符号表并构建索引

找到一个符号表节后，它的sh_link字段指向对应的字符串表节。字符串表就是一大块以\0分隔的字符串，符号项里的st_name是一个偏移，从这个偏移处截取直到下一个\0就是符号名。

def collect_symbols(data, shdrs, sh_type_filter=(2, 11)): results = [] shstr_sec = shdrs[e_shstrndx] shstrtab = data[shstr_sec[4]: shstr_sec[4] + shstr_sec[5]] for idx, sh in enumerate(shdrs): if sh[1] not in sh_type_filter: continue strtab_sec = shdrs[sh[6]] strtab = data[strtab_sec[4]: strtab_sec[4] + strtab_sec[5]] for off in range(sh[4], sh[4] + sh[5] - sym_size, sym_size): st_name, st_info, _, _, st_value, st_size = \ struct.unpack_from(sym_fmt, data, off) sname = strtab[st_name: strtab.find(b'\0', st_name)] if sname.startswith(b'\0') or st_value == 0: continue results.append((st_value, st_size, sname.decode(errors='replace'), idx)) return sorted(results, key=lambda x: x[0])

这里有个细节：shdr[4]是sh_offset，shdr[5]是sh_size，所以节内容在文件里的范围是[sh_offset, sh_offset+sh_size)；符号数量就是sh_size / sym_size。同时判断st_value == 0可以把那些未定义符号（一般是导入的外部函数）过滤掉，它们没有代码地址，参与查询只会污染区间。

4.3 二分查找：地址落到哪个函数区间

索引建好后，查询就是二分。这里最稳妥的策略是：找到符号列表中最后一个st_value <= 目标地址的符号，然后判断目标地址是否小于等于st_value + st_size。

有一种特殊情况值得留意：st_size为0的符号（常见于汇编标签或某些弱符号），如果地址恰好等于st_value，也应该命中。我一般在工程里会宽松处理：addr >= st_value and (st_size == 0 or addr < st_value + st_size)。

import bisect def lookup(symbols, addr): values = [s[0] for s in symbols] pos = bisect.bisect_right(values, addr) - 1 if pos < 0: return None va, size, name = symbols[pos][:3] if addr >= va and (size == 0 or addr < va + size): return name return None

实测过几万个符号的ELF，这个二分查找单次查询是微秒级，线上批量解析几千个地址也毫无压力。后面如果想要更快的连续查询，把整个符号表装进内存再用bisect，性能已经足够。

4.4 处理ET_DYN基址和Thumb标志

真实场景里，我们手上的地址往往来自崩溃日志，是运行期地址。前面说过的基址问题，在脚本里必须暴露出来。最简单的处理是在查询前先校准地址：如果传进来的已经是“偏移”形式（比如Android backtrace里pc 0x7a34且库是ET_DYN），那addr2line直接传偏移就行；如果传进来是绝对地址，需要先从/proc/<pid>/maps找到对应映射行的起始地址，减去基址。

另外一个处理不到位就容易翻车的是ARM/Thumb指令架构：Thumb模式下函数地址最低位可能置1（表示Thumb），比如st_value为0x7a20，运行时PC却显示0x7a21。二分查找时要把这个最低位清掉再匹配，也就是addr & ~1。脚本里加上一个strip_thumb = lambda a: a & ~1，是个不起眼但很关键的细节。

5. 实战中那些坑：常见问题与排查技巧

5.1 符号被strip了怎么办

这是最常踩的坑。发布版的so或者可执行文件跑过strip，.symtab整段被删，nm打出来的符号少一大截，只剩动态符号表里的导出函数。此时内部函数、静态函数全部不可见，能查到的只有对外接口。

对策有几个，按性价比排序：

• 保留未strip的镜像文件，单独存档用于线下分析，线上跑的是strip版，不对查询需求妥协；
• 只strip部分符号：strip --strip-unneeded会保留更多调试信息，有些项目用--keep-symbol白名单方式保住关键函数；
• 如果是自己构建的程序，编译时加-g并保存带调试信息的产物，就能用addr2line精确到行。

从另一个角度说，动态符号表.dynsym是运行必需的，strip不会删除，所以.dynsym里的导出函数永远可查。这也解释了为什么很多开源库release包虽然优化过，但关键API还是能查到函数名——那是给动态链接器留的。

5.2 内联、尾调用与静态函数

即使符号表完整，也会遇到“地址在函数A区间里，但真实来源是函数B”的场景。最常见的是编译器内联：Foo()被内联进Bar()的机器码，符号表里的Foo根本没有对应的独立代码段。这种情况下能给出的最优答案是“曾经属于Foo的源码行被编译进Bar了”，如果没有DWARF行号信息，仅靠符号表无法分辨。

尾调用优化也类似：A()末尾调用B()，编译器直接跳转而不是call，栈回溯会变得“缺失”一层。这个属于栈回溯本身的问题，只做地址到函数名映射解决不了，心里要有数。

静态函数（局部符号）因为STB_LOCAL，在.symtab里是小写t，在.dynsym里根本不出现。如果目标文件被strip过.symtab，静态函数就彻底查不到了。建议在失败时对用户给出“函数可能为静态或已被内联”的提示，而不是直接显示unknown了事。

5.3 内核场景：kallsyms与模块地址

内核的排查和用户态不太一样。内核符号表不在普通ELF文件里，而在/proc/kallsyms里（需要权限）。查它的方式反而是字符串匹配：

grep ' foo_bar' /proc/kallsyms

/proc/kallsyms每一行是“地址 类型 符号名”，类型t/T表示代码。内核模块则是独立分配的地址空间，加载时从/proc/modules和/sys/module/<name>/sections/.text可以查到模块基址。原理和ELF完全一致：模块里函数符号的st_value是相对基址偏移，加上模块加载地址才是可执行地址。内核panic栈里[+ffffffc0001234]这样的后缀，也经常要用这套思路去算偏移。

5.4 动态链接下的PLT/GOT陷阱

如果你的目标是理解“运行时这个地址跳到哪里”，光看ELF符号表可能不够。动态链接的导入函数，在ELF里通常只有一个未定义符号st_shndx==SHN_UNDEF，指向该符号的代码是PLT桩（比如libfoo.so里的plt段）。你用运行地址反查到Foo@plt，其实并没有真正得到被调用者Foo的实现地址——GOT里存储的才是解析后的真实目标。

对于崩溃分析，我们关心的大多是PC当前执行位置，符号表反查够用；但在做动态追踪、inline hook、调用链还原时，必须结合重定位表（.rela.plt）和GOT内容看。这也是为什么热词里会有“relocations in generic elf”——很多人在读ELF做符号分析时，会把重定位表、动态符号表、GOT三者的角色混淆。记住一句话：符号表描述“这个符号长什么样”，重定位表描述“这个符号在哪里被引用”，GOT描述“这个符号跳转的真实地址”。

6. 完整案例：一次native崩溃从地址到定位

把前面所有点串起来看一遍。假设收到一份移动端web内核崩溃日志，类似项目里常见的xweb这些WebView组件：

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) backtrace: #00 pc 0x00000000003d7f04 /data/app/.../lib/arm64/libwebcore.so #01 pc 0x00000000003a22e8 /data/app/.../lib/arm64/libwebcore.so

第一步，拿file确认ELF类型：

file /data/app/.../lib/arm64/libwebcore.so # ELF 64-bit LSB shared object, ARM aarch64

第二步，如果希望精确定位行号，用带debug信息的构建产物：

addr2line -f -C -e build_unstripped/libwebcore.so 0x3d7f04

如果构建产物刚好带-g，输出会带ChromiumWebView::DispatchTouchEvent()加文件名:行号。如果只有release版，nm -n看区间也基本能定位函数范围。

第三步，如果日志给的是绝对地址而不是偏移，就要用maps校准。找到这条映射的起始地址：

7f8a2c3d0000-7f8a2c5d0000 r-xp /data/app/.../lib/arm64/libwebcore.so

那么偏移就是abs_addr - 0x7f8a2c3d0000。

第四步，批量处理。线上系统不可能一个个手工敲addr2line，一般会写个脚本循环处理。用我前面那个解析器，把崩溃日志里的地址全部读进来，一分钟能解析上千个地址，直接输出结构化结果。

第五步，遇到查不到的情况，按优先级排查：是不是基址没减？是不是strip了？是不是Thumb位没清？这三级排查能解决90%的“符号找不到”。

整个流程跑通之后，线上native崩溃从收到日志到给出可读栈，基本能控制在分钟级。很多平台的崩溃服务后端就是干这件事，原理和我上面描述的一模一样。

我自己在这条路上踩过最大的坑，是早期直接拿运行时地址去查符号表，没做基址校准，白查了半天。还有一次写解析器没处理Thumb位，在ARM平台上报了一堆错位函数名。后来把这些边界情况全写进工具里，再遇到再刁钻的日志，都先走一遍：校验ELF类型、取节头表、过滤STT_FUNC、二分匹配、基址校准、demangle。这套流程虽然简单，却非常稳，值得当作通用模板沉淀下来。

如果你也想自己维护一个地址反查工具，建议一开始就把readelf -s的命令输出解析和自研深度解析两条路都写上，遇到诡异的ELF还能用readelf的原始输出做参照对拍，排查起来会轻松很多。