On Mon, Jun 29, 2015 at 8:13 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Sun, Jun 28, 2015 at 07:29:39PM -0400, Ayaz Akram wrote: >> > Let's say qemu is running in System Emulation Mode, when it runs guest's
System emulation makes the problem even harder, as a system mode binary (usually an OS or some sort) will have difficult porting from one CPU-types system arch to another. This is more realistic (but still very difficult and not generally solvable) in user-mode emulation. >> > binary, it can log the translated code for host. Is it possible to merge >> > that translated code and other sections of guest's binary to make a binary >> > which can be run directly on host. > > No, because of self-modifying code, run-time code loading, etc. > Ruling these two out for the moment ... > It is not possible to statically translate an executable (in the general > case). > > There are architectures where it is possible due to restrictions (e.g. > no code loading, all jump destinations are known in advance, etc) but Debug info with function information might give you a crude approximation of jump targets coming from fn pointers. That + the statically determinable jump targets might give you something for apps that don't do anything wierd. I'm wondering if the jump problem can be crudely solved by a fully single-step translation. The result binary would be huge an inefficient. But could you keep two translations around? One that uses the statically determinable "best guess" of the jump dest table I describe above, and a second defensive translation of the entire app in single-step? There are more complications however. Another one I can think of is instructions that change runtime state and affect (re)translation (e.g. the arm setend instruction which switches CPU endianness). Regards, Peter > the popular x86, ARM, etc architectures allow too much freedom to be > amenable to static translation. > > Stefan
