readelf是Linux环境下解析ELF文件不可或缺的工具，熟练掌握它，你就能直接读懂程序的二进制骨骼，从而在调试、逆向分析和性能优化中占据主动。
readelf命令详解：从基础到高级用法
readelf名字本身就说明了一切读取ELF格式文件，无论是可执行文件、目标文件还是共享库，只要遵循ELF规范，readelf都能帮你把内部结构拆解得明明白白，它不需要依赖目标文件架构，因此比部分专用工具更通用。
常用参数速览
-h：显示文件头，包含入口地址、节区数量、程序头数量等关键信息。-l：显示程序头，也就是段（segment）信息，加载器根据它把程序映射到内存。-S：显示节区头（section headers），每个节区的名称、类型、地址、偏移量一览无遗。-s：显示符号表，包括函数名、全局变量等，是调试和逆向的利器。-r：显示重定位条目，了解链接时如何修正地址。-d：显示动态段信息，动态链接器依赖它完成运行时绑定。-n：显示注释信息，常常包含编译器版本、构建ID等。-a：显示所有可用信息，相当于一次跑完上面大部分参数，但信息量极大。
如何查看文件头
运行 readelf -h <filename>，你会看到类似下面的输出：
- 类别：ELF32还是ELF64，直接告诉你程序是32位还是64位。
- 字节序：小端（Little Endian）还是大端（Big Endian）。
- 入口点地址：程序从哪条指令开始执行。
- 程序头起点和节区头起点：解析后续结构的指针。
这些信息是理解任何ELF文件的起点,也是排查文件损坏或格式不匹配问题的第一站。
解析节区结构
readelf -S 输出节区表，每个节区都有名称（如.text、.data、.bss）、类型、标志、地址、偏移量等，举个例子，.text节区存放代码，.data存放已初始化全局变量，.bss存放未初始化全局变量，通过观察这些节区的地址范围和大小，你能推断出程序的内存布局，这在分析链接脚本或内存溢出问题时非常有用。
readelf和objdump区别：什么时候该用谁
很多开发者会混淆readelf和objdump,因为它们都操作ELF文件，但这两者的设计目标完全不同，行业共识认为，readelf专注于解析ELF结构本身，而objdump更侧重于反汇编和内容转储。
核心差异
| 对比维度 | readelf | objdump |
|---|---|---|
| 主攻方向 | 显示ELF结构元数据 | 反汇编代码、转储数据 |
| 依赖架构 | 否，独立于目标的机器架构 | 是，需要了解目标架构才能反汇编 |
| 常见用途 | 排查链接问题、检查符号、理解段布局 | 分析代码逻辑、查看指令序列 |
| 输出格式 | 结构化、易读，适合快速理解组织 | 详细，但更偏向底层字节 |
当你需要检查一个动态库导出了哪些函数,或者确认某个符号是否被正确链接时，readelf -s 是最直接的选择，而如果你想看某段函数的汇编代码，objdump配合 -d 才是正解，两者是互补关系，而不是替代关系。
实际场景选择
- 场景1：你拿到一个第三方库，想确认它是否包含某个特定函数，用
readelf -s libxxx.so | grep function_name
- 场景2：你想分析一个崩溃时的程序计数器（PC）指向的代码，先用objdump反汇编，再用readelf查看对应节区的地址范围，从而定位到具体函数。
在Linux调试和逆向实践中,两个工具常常配合使用，但单纯从解析ELF结构的角度，readelf更专业、更轻量。
readelf实战：解决日常开发中的疑难杂症
检查动态链接库的符号冲突
当程序运行时出现“undefined symbol”或“symbol lookup error”，往往是符号表出了问题，使用 readelf -s 可以列出所有全局符号，配合 grep 过滤目标函数名，检查它是否被导出，或者是否被多个库同时定义，在交叉编译项目中，经常需要验证目标板上的库是否与主机上的库符号一致，readelf就是在不同环境间比对符号的可靠工具。
验证程序入口和段加载地址
在嵌入式开发或内核调试中,需要确认程序入口点和段加载地址是否符合预期，用 readelf -h 查看入口点，用 readelf -l 查看程序头中的LOAD段，对比链接脚本定义的地址，就能快速定位配置错误，据统计，超过七成的内核启动问题都源于入口地址或段偏移设置不当（行业经验数据，非精确统计）。
检测文件完整性
有时怀疑文件被截断或损坏,但ldd或运行时报错太笼统，用 readelf -h 查看文件头中的 section header string table index 和 section header offset，如果这些值超出文件大小范围，说明文件大概率不完整。readelf -a
会在解析过程中报告错误，Error: Reading XXX bytes past end of file”，这种直接反馈比任何猜测都准确。
分析bss段大小
bss段的大小直接影响程序的内存占用。readelf -S 中.bss节区的Size字段就是它的实际大小，如果程序在运行时占用内存远超预期，先检查bss段是否过大，再排查是否有未初始化的全局数组或结构体，很多性能优化案例都从压缩bss段占用的内存开始。
常见问题与解答
readelf报错“not an ELF file”怎么办
首先确认文件是否真的是ELF格式,可以用 file 命令查看，如果文件是压缩包或脚本，readelf自然无法识别，如果文件确实是ELF但报错，可能是文件头被破坏，或者文件是静态链接但缺少某些关键结构，建议用 readelf -h 单独检查，看能否读出基本字段，如果不能，考虑使用 hexdump 手动查看文件头魔数（0x7f ‘E’ ‘L’ ‘F’）是否完整。
readelf和objdump在显示符号表时有什么区别
readelf直接输出原始符号表内容,包含符号类型、绑定属性、所属节区等元数据，格式清晰，objdump的 -t 也能显示符号表，但输出更偏向于反汇编上下文，且对动态符号的展示不如readelf细致，在需要分析符号可见性（如全局、弱符号）或符号版本信息时，readelf是更可靠的选择。
如何用readelf查看一个库支持哪些架构
使用 readelf -h 查看文件头中的“Machine”字段，ARM”对应32位ARM，“AArch64”对应64位ARM，“x86-64”对应64位x86，如果文件是“Intel 80386”则是32位x86，这个字段是判断库是否能在目标平台运行的第一道验证，比依赖于文件名或后缀更准确。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/linux-readelf%e5%91%bd%e4%bb%a4%e6%80%8e%e4%b9%88%e7%94%a8%ef%bc%9f%ef%bc%8c%e6%9c%89%e4%bb%80%e4%b9%88%e7%94%a8/
