为什么动态二进制翻译比静态二进制翻译更实用？答案

【问题标题】：Why is dynamic binary translation more practical than static binary translation?为什么动态二进制翻译比静态二进制翻译更实用？
【发布时间】：2013-05-19 10:37:12
【问题描述】：

当谈到二进制翻译（重新编译）时，我一直听说动态二进制翻译通常比静态二进制翻译更好，但我似乎永远无法理解这背后的原因。为什么总是认为无法在仿真中实现静态二进制翻译？为什么动态二进制翻译总是被认为更实用？

人们经常将其与 JIT（即时）和静态编译之间的关系进行比较，但这种比较常常会让我感到困惑，因为两者都不仅仅是实际的实现。

【问题讨论】：

标签： c assembly compiler-construction binaryfiles

【解决方案1】：

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

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

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

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

【讨论】：

这个答案听起来有点奇怪。如果加载程序（以及运行时库 - 例如 C 的 ctr）做得很好，为什么识别程序的某些部分会很复杂？实现 DTB 的延迟不是很大吗？
操作系统加载器从可执行文件中的元数据中获得完成工作所需的所有帮助。像重定位表和导入导出表。没有等效的表格说明文本段中的字节是代码与数据。