Re: [Qemu-devel] QEMU to generate host binary

[Peter Crosthwaite]

On Mon, Jun 29, 2015 at 8:13 AM, Stefan Hajnoczi <address@hidden> 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