需先调用elf.open()打开文件，再立即检查f.fileheader是否非零或调用f.type()触发解析，否则无效elf文件可能延迟报错；fileheader为零说明魔数错误、非elf或读取不全。
如何用 debug/elf 打开一个 ELF 文件并确认格式有效
直接调用 debug/elf.Open 是最常用入口，但它不校验文件是否真为合法 ELF —— 即使传入 PNG 或空文件，也可能返回非 nil 的 *elf.File，直到你访问具体字段才 panic。务必在打开后立刻检查 f.FileHeader 是否非零，或调用 f.Type 等轻量方法触发基础解析：
f, err := elf.Open("binary")
if err != nil {
log.Fatal(err)
}
// 强制触发 header 解析，避免后续 panic
if f.FileHeader == nil {
log.Fatal("not a valid ELF file")
}
- 常见错误：跳过这步，后续调用
f.Sections()或f.Symbols()时突然 panic "invalid ELF magic" -
elf.Open不会自动 mmap，整个文件被读入内存；大文件（如 >500MB）需考虑用elf.NewFile配合自定义io.ReaderAt - 注意：
elf.Open会尝试识别并处理 ET_DYN（PIE）和 ET_EXEC，但不会重定位符号地址 —— 它只做静态解析
为什么读不到 .text 段的原始字节，而 Sections() 返回空 slice
ELF 规范中 “段（segment）” 和 “节（section）” 是两套不同视图：f.Sections() 返回的是链接视图（section header table），而 .text 这类名字实际属于节名；但很多 stripped 二进制会被 strip 掉 section header table，导致 f.Sections() 返回空，即使程序能正常执行。
- 验证方式：用
readelf -S binary查看是否有 SHF_ALLOC 标志的节；若输出为空或提示 "Section headers are not available"，说明 section header 已被删除 - 此时应改用
f.Progs()获取程序头（program headers），它对应加载视图，包含可执行段（如 PT_LOAD 类型），再用p.ReadAt()读取原始字节 -
f.Section(".text")在无节表时返回 nil，不是 bug，是设计如此 —— Go 的debug/elf严格遵循 ELF spec 分离两种视图
解析符号表时 Symbol.Name() 返回空字符串或乱码
符号名存储在独立的字符串表（.strtab 或 .dynstr）中，Symbol.Name() 内部依赖该表；如果符号表（.symtab 或 .dynsym）的 sh_link 字段指向无效索引，或字符串表本身被裁剪，就会出问题。
- 先确认符号表存在：
symtab := f.Section(".symtab"); if symtab == nil { symtab = f.Section(".dynsym") } - 再检查字符串表：
strtab := f.Section(symtab.SectionHeader.LinkName())，若为 nil，说明符号名不可用 - stripped 二进制通常只保留 .dynsym + .dynstr（动态符号），而丢弃 .symtab/.strtab；此时
f.Symbols()仍可返回部分符号，但 Name 可能为空 - 绕过方法：用
symtab.Data()手动解析符号结构（elf.Symbol64），再用strtab.Data()做偏移查表 —— 但需注意 endianness 和版本对齐
在交叉编译目标平台（如 arm64 Linux）上解析 x86_64 ELF 会失败吗
不会。Go 的 debug/elf 是纯 Go 实现，不依赖系统 libc 或 binutils，完全基于字节流解析，与宿主机架构无关。只要 ELF 文件格式合法，就能解析其 header、program headers、section headers、symbol table 等所有标准结构。
- 唯一例外是某些非常规扩展：比如 vendor 自定义的 section 类型或非标准 flag，
debug/elf会跳过而非报错 - 性能影响极小：解析 10MB ELF 通常在毫秒级，主要耗时在 I/O 和内存拷贝，而非 CPU 解码
- 注意：
Symbol.Value是文件内偏移（对于 .symtab）或运行时虚拟地址（对于 .dynsym），别直接当内存地址用 —— 它没有重定位上下文
真正容易被忽略的是：ELF 中大量字段含义依赖于 e_type、e_machine 和是否启用动态链接，同一字段（如 ProgramHeader.Paddr）在 ET_EXEC 和 ET_DYN 下语义不同；不结合上下文直接解读，十有八九会误判。
