我不认为有任何可靠的方法来做到这一点。 机器码格式非常复杂，比assembly文件更复杂。 编译的二进制文件(比如ELF格式文件)并不是真的有可能产生一个源代码汇编程序，它将编译成相同的(或类似的)二进制文件。 为了理解差异，将GCC编译直接输出到汇编器( gcc -S )的输出与objdump在可执行文件( objdump -D )上的输出进行比较。
我可以想到两个主要的并发症。 首先，由于指针偏移等原因，机器码本身并不是与汇编代码一一对应的。
例如，考虑C代码到Hello世界：
int main() { printf("Hello, world!\n"); return 0; }
这编译为x86汇编代码：
.LC0: .string "hello" .text movl $.LC0, %eax movl %eax, (%esp) call printf
其中.LCO是一个命名常量，printf是共享库符号表中的一个符号。 比较objdump的输出：
80483cd: b8 b0 84 04 08 mov $0x80484b0,%eax 80483d2: 89 04 24 mov %eax,(%esp) 80483d5: e8 1a ff ff ff call 80482f4
首先，常量.LC0现在只是内存中的某个随机偏移量 – 在正确的位置创build一个包含这个常量的汇编源文件是很困难的，因为汇编器和链接器可以自由select这些常量的位置。
其次，我不完全确定(这取决于位置独立的代码)，但我相信对printf的引用实际上并没有在那里的代码中的指针地址编码，但ELF头包含一个查找表，它在运行时dynamic地replace它的地址。 因此，反汇编代码并不完全对应源代
