C 为什么动态二进制翻译比静态二进制翻译更实用?

C 为什么动态二进制翻译比静态二进制翻译更实用?,c,assembly,compiler-construction,binaryfiles,C,Assembly,Compiler Construction,Binaryfiles,当谈到二进制翻译(重新编译)时,我总是听说动态二进制翻译通常是静态二进制翻译的更好的替代方法,但我似乎永远无法理解这背后的原因。为什么人们总是认为静态二进制翻译不可能在仿真中实现?为什么动态二进制翻译总是被认为更实用 人们经常将其与JIT(即时)和静态编译之间的关系进行比较,但这种比较常常会让我感到困惑,因为两者都有更多的实际实现。当必须将机器代码从一种体系结构转换到另一种体系结构时,就会出现这种情况。静态地执行此操作需要能够正确识别程序中表示代码的部分,并且不会被二进制图像中实际上是数据的位所

当谈到二进制翻译(重新编译)时,我总是听说动态二进制翻译通常是静态二进制翻译的更好的替代方法,但我似乎永远无法理解这背后的原因。为什么人们总是认为静态二进制翻译不可能在仿真中实现?为什么动态二进制翻译总是被认为更实用


人们经常将其与JIT(即时)和静态编译之间的关系进行比较,但这种比较常常会让我感到困惑,因为两者都有更多的实际实现。

当必须将机器代码从一种体系结构转换到另一种体系结构时,就会出现这种情况。静态地执行此操作需要能够正确识别程序中表示代码的部分,并且不会被二进制图像中实际上是数据的位所混淆。许多编译器并没有做到这一点,任何试图反编译可执行文件的人都知道这一点

一个简单的例子是从C中的switch语句生成的跳转表,它与可执行代码一起编译成.text段。此表包含地址,而不是代码。要知道如何将这些字节解释为地址,需要了解编译器内置的代码生成器。这不是不可能的,但它当然不会在另一个编译器生成的代码上很好地工作。甚至是同一编译器的不同版本

动态翻译不是问题,您知道字节块是代码,因为机器正在尝试执行它


另一种考虑适用于抖动,这样的翻译器将永远不会有识别代码的问题,因为中间代码的设计使它变得容易。在这种情况下,动态翻译是可取的,因为它可以随着时间的推移分散翻译的开销,从而减少程序执行中的暂停。并且完全避免对从不执行的代码进行操作。

这个答案听起来有点奇怪。如果一个加载器(以及运行时库,比如ctr for C)做得很好,为什么识别程序的某些部分会很复杂?实现DTB的延迟不是很大吗?OS加载器可以从可执行文件中的元数据获得完成其工作所需的所有帮助。类似于重新定位表和导入导出表。没有等效的表表明文本段中的字节是代码与数据。