c++如何读取和修改ELF文件的符号表信息_Linux底层开发【附代码】-C++-PHP中文网

直接读取elf符号表会段错误，因sh_addr是运行时虚拟地址而sh_offset才是文件内真实偏移；需用readelf -s确认offset、sh_type及sh_entsize，修改符号名须重写整个.strtab并更新sh_size与st_name。

c++如何读取和修改elf文件的符号表信息_linux底层开发【附代码】

直接读取 ELF 符号表会段错误？先确认 `sh_addr` 和 `sh_offset` 是否有效

ELF 文件的符号表（.symtab 或 .dynsym）不一定加载到内存，也未必在文件头中被直接映射。很多工具（比如自己用 mmap 读取后硬算 sh_addr）会崩溃，就是因为误把虚拟地址当文件偏移——sh_addr 是运行时地址，sh_offset 才是文件内真实字节位置。

实操建议：

用 readelf -S a.out 确认目标节区（如 .symtab）的 Offset 字段，它对应 sh_offset
检查该节区的 sh_type 是否为 SHT_SYMTAB（0x2）或 SHT_DYNSYM（0xb），避免读错节
符号表条目大小固定：sizeof(Elf64_Sym)（通常 24 字节），但 32 位 ELF 是 16 字节，必须按实际 ELF class 判断
别跳过 sh_entsize 字段——有些自定义工具会改它，硬写 24 容易越界

修改符号名字符串需重写整个 `.strtab` 节区，不能只 patch 字符串

符号名存在独立的字符串表节（.strtab 或 .dynstr），所有 st_name 字段只是该节内的偏移。想改一个符号名，本质是：在字符串表里追加新字符串 → 更新对应 st_name 值 → 调整节区头 sh_size → 可能还要修正后续节区的 sh_offset（如果文件要保持可加载）。

常见错误现象：

只改了 st_name 指向的旧字符串内容，结果其他符号名也被截断或覆盖（因为字符串表里是 \0 分隔的连续内存）
没更新 .strtab 的 sh_size，导致 readelf 显示乱码或报 Warning: bad string table index
新增字符串后未重写整个 .strtab 节区，而是用 pwrite 零散写入，破坏原有对齐或填充

最小可行做法：读出完整 .strtab 内容 → 构造新字符串池（保留原字符串 + 追加新名 + \0）→ 用 pwrite 一次性覆写整个节区 → 更新节头 sh_size 和所有引用它的 st_name 值。

用 `libelf` 比裸写 `read`/`lseek` 更安全，但要注意 `elf_update()` 的 mode 参数

libelf 封装了节区定位、重定位和校验逻辑，但新手常卡在 elf_update(elf, ELF_C_WRITE) 失败——这其实是只写模式，不支持扩展节区；想增大 .strtab 必须用 ELF_C_WRITE_MMAP 或先调 elf_flagelf(elf, ELF_F_DIRTY) 标记脏状态。

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

关键参数差异：

ELF_C_WRITE：仅允许修改已有字节，sh_size 增大直接返回 -1
ELF_C_WRITE_MMAP：允许扩大节区，但要求文件已用 elf_memory() 或 mmap() 映射且可写
必须调 gelf_getsym() / gelf_update_sym() 处理符号，而非直接操作 Elf64_Sym* 内存，否则结构体字段可能因版本不匹配错位

示例片段（简化）：

Elf *e = elf_begin(fd, ELF_C_RDWR, NULL);
GElf_Shdr shdr;
gelf_getshdr(elf_getscn(e, symtab_ndx), &shdr); // 获取 .symtab 节头
// ... 定位并修改某个符号的 st_name ...
gelf_update_sym(elf_getscn(e, symtab_ndx), idx, &sym);
elf_update(e, ELF_C_WRITE_MMAP); // 注意这里

动态符号表 `.dynsym` 修改后，`ldd` 不报错但程序 segfault？检查 `DT_HASH`/`DT_GNU_HASH` 是否同步更新

Linux 动态链接器不只查 .dynsym，还依赖哈希表（.hash 或 .gnu_hash）加速符号查找。改了 .dynsym 却不重建哈希表，会导致链接器找不到符号或索引越界。

实操要点：

.hash 结构含 nbucket 和 nchain，必须按新符号数量重算，并重填 bucket[] 和 chain[] 数组
.gnu_hash 更复杂，包含 Bloom filter 和不同长度的 hash 链，手动生成极易出错；建议用 objcopy --strip-unneeded 后重新 gcc -shared 生成，而非现场修补
可用 readelf -d ./a.out | grep HASH 确认当前使用的是哪种哈希机制