ELF核心文件格式
如果没有深入研究 GDB 源代码，我在哪里可以找到有关用于创建核心文件的格式的文档？
ELF 规范使核心文件格式保持开放，所以我想这应该是 GDB 规范的一部分！遗憾的是，我没有从 GNU 的 gdb 文档中找到这方面的任何帮助。
这就是我想要做的：将虚拟地址映射到包含正在运行的进程的可执行文件/库中的函数名称。为此，我首先想从核心文件中找出从虚拟地址空间到可执行文件/库名称的映射，然后深入相关文件以获取符号信息。
现在“readelf -a core”告诉我，核心文件中的几乎所有段都是“load”类型——我猜这些是来自所有参与文件的.text和.bss/.data段，加上堆栈段。除了这些负载段之外，还有一个注释段，但似乎不包含地图。那么一个段对应哪个文件的信息，是如何存储在core文件中的呢？这些“加载”段格式是否以特定方式包含文件信息？
Short of digging through GDB source, where can I find documentation about the format used to create core files?
The ELF specification leaves the core file format open, so I guess this should be part of the GDB specifications! Sadly, I did not find any help in this regard from GNU's gdb documentation.
Here's what I am trying to do: Map virtual addresses to function names in executable/libraries that comprised the running process. To do that, I would first like to figure out, from the core file, the map from virtual address space to the name of the executable file/libraries, and then dig into the relevant file to get the symbolic information.
Now 'readelf -a core' tells me that nearly all the segments in the core file are of the type 'load' -- I'd guess these are the .text and .bss/.data segments from all the participating files, plus a stack segment. Barring these load segments, there is one note segment, but that does not seem to contain the map. So how is the information about which file a segment corresponds to, stored in the core file? Are those 'load' segments format in a particular way to include the file information?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
核心转储文件格式使用 ELF 格式，但 ELF 标准中没有描述。 AFAIK，这方面没有权威参考。
ELF 注释中包含许多额外信息。您可以使用 readelf -n 来查看它们。
CORE/NT_FILE 注释定义了内存地址范围和文件（+ 偏移量）之间的关联：
对于每个线程，您应该有一个 CORE/NT_PRSTATUS 注释，它为您提供线程的寄存器（包括堆栈）指针）。您也许可以从中推断出堆栈的位置。
有关 ELF 核心文件格式的更多信息：
ELF 剖析核心文件（免责声明：我写了这个）
核心转储简介
The core dump file format is using the ELF format but is not described in the ELF standard. AFAIK, there is no authoritative reference on this.
A lot of extra information is contained within the ELF notes. You can use
readelf -nto see them.The CORE/NT_FILE note defines the association between memory address range and file (+ offset):
For each thread, you should have a
CORE/NT_PRSTATUSnote which gives you the registers of the thread (including the stack pointer). You might be able to infer the position of the stacks from this.More information about format of ELF core files:
Anatomy of an ELF core file (disclaimer: I wrote this one)
A brief look into core dumps
核心转储是进程崩溃时的内存中映像。它包括程序段、栈、堆和其他数据。您仍然需要原始程序才能理解内容：符号表和其他数据使内存映像中的原始地址和结构有意义。
A core dump is the in-memory image of the process when it crashed. It includes the program segments, the stack, the heap and other data. You'll still need the original program in order to make sense of the contents: the symbol tables and other data make the raw addresses and structures in the memory image meaningful.
与其说是 gdb，不如说是 gdb、binutils 等使用的 bfd 库。
Not so much
gdbas thebfdlibrary used bygdb,binutils, etc.有关生成核心文件的进程的附加信息存储在 ELF 注释部分中，尽管是以操作系统特定的方式。例如，请参阅 core(5) 手册页了解 NetBSD。
Additional information about the process that generated the core file is stored in an ELF note section, albeit in an operating system specific manner. For example, see the core(5) manual page for NetBSD.
解决问题的一个更简单的解决方案可能是解析 /proc/$pid/maps 中的文本以确定给定的虚拟地址映射到哪个文件。然后就可以解析对应的文件了。
Kenshoto 的开源 VDB（调试器）就使用了这种方法，如果你能读懂 python，它就是一个很好的例子。
A simpler solution to your problem may be to parse text from /proc/$pid/maps to determine what file a given virtual address maps to. You could then parse the corresponding file.
Kenshoto's open source VDB (debugger) uses this approach, if you can read python it is a good example.