为什么 objdump 生成的程序集很大？答案

【问题标题】：Why assembly produced by objdump is huge?为什么 objdump 生成的程序集很大？
【发布时间】：2016-02-14 14:55:26
【问题描述】：

我正在尝试查看我的简单 C 应用程序的程序集。因此，我尝试使用objdump 从二进制文件生成程序集，它会生成大约 4.3MB 大小的文件，其中包含103228 行汇编代码。然后，我尝试通过向gcc 提供-S 和-save-temps 标志来做到这一点。

我使用了以下三个命令：

 1. arm-linux-gnueabi-objdump -d hello_simple > hello_simple.dump
 2. arm-linux-gnueabi-gcc -save-temps -static hello_simple.c -o hello_simple -lm
 3. arm-linux-gnueabi-gcc -S -static hello_simple.c -o hello_simple.asm -lm

在 2 和 3 的情况下，产生完全相同的结果，即 65 行汇编代码。我知道objdump 也会产生一些额外的细节。

但是，为什么会有巨大的差异？

EDIT1：我已使用以下命令构建该二进制文件：

arm-linux-gnueabi-gcc -static hello_simple.c -o hello_simple -lm

EDIT2：虽然，-static 和 -lm 标志在这里看起来可能是不必要的，但是，我必须在编译时添加一些程序集组件之后在模拟器上执行这个二进制文件，这使得它们成为必须的。

那么，在分析执行跟踪期间，我应该考虑哪些汇编代码最相关？（我知道这是另一个问题，但在同一个答案中涵盖它会很方便。）

【问题讨论】：

.debug_info 我猜？尝试先剥离
如果您的程序使用-static 链接，它还将包含libc 和其他链接到可执行文件的库。这些也会被objdump 倾倒。
回复：您的最后一次编辑。 -static -lm 对 command 3 没有影响。 它们显然对其他命令有影响，因为它们确实生成二进制文件。
这是命令 2.，它们确实有效果，就像我说的那样。
为什么两个反对票和两个赞成票没有任何评论？我认为 SO 哲学是帮助和指导，而不仅仅是谴责。如果也有一些 cmets，我至少会学到一些东西。

标签： c debugging gcc assembly objdump

【解决方案1】：

后两个只是为您的函数保存 asm。

第一个也有 CRT 启动代码。而且，由于您静态链接它，因此您调用的所有库函数。

请注意，对于 3，-static 和 -lm 不执行任何操作，因为您没有进行链接。 gcc foo.c -S -O3 -fverbose-asm -o- | less 通常很方便。

我注意到您的命令行中没有一个包含-O3 或-march=。您应该使用优化进行编译，并让 gcc 针对目标硬件优化您的代码。

.s 是机器生成的 asm 的标准后缀。（.S 用于手写 asm：gcc foo.S 将首先通过 cpp 运行它）。 gcc -S 产生一个.s，同样的方式-c 产生一个.o。

对于 x86，.asm 通常仅用于 Intel 语法 (NASM/YASM)，但 IDK 的约定是用于 ARM。

那么，在分析执行跟踪时，我应该考虑哪些汇编代码最相关？

这取决于你想学什么！如果您对每个库函数调用的“昂贵”程度有很好的了解（就指令数量、污染分支预测器的分支数量和数据缓存污染而言），那么您不需要通过跟踪执行库调用。如果您有一些内部循环使用的数学库函数，那么如果代码对时间要求很高，那么值得查看它们。

不过，通常探查器或调试器中的单步执行对此很有用。仅仅有大量库代码的反汇编输出通常只是混乱。

【讨论】：