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

[Ayaz Akram]

Thanks for your answers. The thing that i still do not get is once we have host assembly code (output assembly log generated for compiled TBs ), should we still worry about problems like self modifying code and other dynamic conditions? Moreover, assuming static linking, will not this code be enough to generate .text section of an executable that could be run directly on host (if somehow other sections of that host executable can be generated, which is itself difficult) ?

On Mon, Jun 29, 2015 at 1:04 PM, Peter Crosthwaite <address@hidden> wrote:

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