GDB调试过程中的asm代码来自哪里？

Question

基本上，根据我的知识，

如果我们使用GDB来调试从C源代码编译的执行代码， 编译器会将源代码Path留在ELF / PE文件中，所以 GDB将使用源代码来促进我们的调试过程。

但GDB如何在上述过程中提供asm代码信息？我举一个在我的电脑上捕获的例子如下：

所以我的问题是：

1. GDB如何提供asm代码？这是由反汇编生成的asm代码吗？
2. 如果是这样，那么GDB如何保证拆卸的准确性？ 我知道像OBJDUMP这样的线性反汇编算法无法区分数据和代码，像IDA pro这样的商业工具也会不时出错

有人能给我一些帮助吗？谢谢！

Answer 1

请记住，“编译器”（例如gcc）可以做几件事：

• 预处理（#includes，macros等）
• 正确编译（将预处理的c转换为汇编）
• 程序集（将程序集转换为目标代码）
• link（适当地将对象打包成库/可执行文件）

到目前为止，最复杂的部分是编译适当的阶段。

还要记住，汇编或多或少是对象代码中包含的机器指令的直接表示。

所以，回答你的问题：

1. GDB读取您的库/可执行文件，并且通常（相对）提取机器指令，从而提取汇编代码。这是反汇编过程。
2. 同样，由于GDB直接从库/可执行文件获取机器指令/目标代码，只要它能够准确地将机器代码转换为汇编指令，提供准确的反汇编就不会有太多问题。 / LI>

   换句话说，从源代码到汇编有一个1：多的映射，这意味着给定源代码的汇编代码有许多可能的排列，给定不同的编译器，编译器选项等。这意味着很难，如果不是不可能从纯对象代码派生源代码。因此，为了有效地调试c源代码，源代码必须可用于GDB，无论是嵌入还是原始.c形式。

   相反，更接近于从汇编代码到目标代码的1：1映射，因为两者都或多或少代表相同的东西 - 创建给定程序所需的内存中指令的布局。因此，反汇编过程比任何潜在的“反编译”过程都要简单得多。