GCC 调试信息
我正在使用 GCC ARM 交叉编译器 (arm-none-eabi-*) 并使用专有的调试器。调试器可以突出显示所选源代码行的结果汇编。使用 nm 和 objdump，我可以看到二进制文件有多个 .debug_* 部分。显然，调试器正在使用这些部分中包含的信息将源代码行映射到反汇编（反之亦然）。但我想怎样。我想知道这些部分包含哪些信息、它们之间的关系以及如何理解它们。简而言之，如果我要编写一个调试器（或者至少是一个可以显示这些映射的工具：源到反汇编，然后返回，每个源行的反汇编行数），我将如何阅读这些部分并利用它们。假设零编译优化。
大概有一些文档描述了这些部分的格式？
I'm using the GCC ARM cross-compiler (arm-none-eabi-*) and am using a proprietary debugger. The debugger can highlight resultant assembly for a selected source line. Using the nm and objdump, I can see that the binary has more than one .debug_* sections. It's obvious to conclude that the debugger is using information contained in these sections to map source lines to the disassembly (and vice versa). But I'd like to how. I'd like to know what information these sections contain, how they're related, and how to make sense out of them. In short, how would I read the sections and make use of them, if I were to write a debugger (or at least, a tool that can display these mappings: source to disassembly, and back, number of disassembly lines per source line). Assume zero compilation optimization.
Presumably there's some doc that describes the format of these sections?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
.debug_* 部分包含 DWARF 调试标准描述的格式的数据。该标准有一个网站，您可以在其中下载标准规范：http://www.dwarfstd.org/
有一些库可用于解析存储的格式（高度压缩以节省空间），其中之一是 libdwarf，此处可用： http://reality.sgiweb.org/davea/dwarf.html
简而言之，不同的部分包含源程序的不同方面，以及它们如何映射到目标机器架构（代码和数据地址） ）。通常在编译过程中丢失的信息由调试信息条目树表示，这些条目是具有识别标记和各种属性的结构。例如，变量声明的 DIE 由带有
DW_TAG_variable标记的 DIE 表示，并且可以具有以下属性：名称、声明所在的文件/行/列、对象中的内存位置.debug_info和 .debug_abbrev 部分一起表示调试信息条目树。 .debug_line 部分包含允许调试器重建将源代码行映射到目标代码地址的完整表的信息（并包含其他信息，例如源代码行是否是语句的开头，以及是否是一个语句的开头）。基本块等）。
其他部分包含调用框架信息以及用于按名称快速查找变量 DIE 和类型的加速查找表等。这一切都在标准中进行了描述。
The .debug_* sections contain data in a format described by the DWARF debugging standard. The standard has a web site where you can download the standard specification: http://www.dwarfstd.org/
There are libraries available for parsing the stored format (which is highly condensed to save space), one such is libdwarf available here: http://reality.sgiweb.org/davea/dwarf.html
In short, the different sections contain different aspects of the source program, and how they map to the target machine architecture (code and data addresses). Information which is typically lost in the compilation process is represented by a tree of Debug Information Entries, which are structures with an identifying tag, and various attributes. For example, the DIE for a variable declaration is represented by a DIE with the
DW_TAG_variabletag, and can have such attributes as: name, file/line/column where it is declared, memory location in the object file, etc.The .debug_info and .debug_abbrev sections together represent the tree of Debug Information Entries. The .debug_line section contains information that allows the debugger to reconstruct a complete table mapping source code line to object code address (and contains other information, like whether or not a source code line is the start of a statement, and is the start of a basic block, etc.).
Other sections contain call frame information, and accelerated lookup tables for quickly finding variable DIEs and types by name, and more. It's all described in the standard.