Re: [Qemu-devel] Binary translation (of code)

Re: [Qemu-devel] Binary translation (of code)

[Tarmo Pikaro]

Message: 3
Date: Sun, 08 May 2011 21:41:15 +0200
From: Llu?s <xscript@gmx.net>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Binary translation (of code)
Message-ID: <87ei49ugis.fsf@ginnungagap.bsc.es>
Content-Type: text/plain; charset=utf-8

Tarmo Pikaro writes:

> Hi !
>> > I think self-modifying?code is kinda rare case - it's made typically for
>> > protection againt?hackers , and?typically on pc side. Nintendo?roms 
probably
>> > don't use this kind of
>> > protection.
>> 
>> It doesn't have to be protection, for example GCC generates
>> trampolines to stack when using nested functions.

> Ok, so apparently we will have some challenges on the way.

> I guess some sort of mutation - qemu + recompiler could be done as well...

> It would be much easier to ship an executable containing both the guest
> application and qemu, so that executing it starts qemu with a
> pre-defined configuration and runs the guest binary.
 
- Binary recompilation would allow faster execution than emulated code
 
- qemu constantly changes (based on amount of patches provided in this
mail list) - in order to keep image+qemu working - simplest way is to convert 
into
executable. Btw - qemu could be used as a bootstrap to image as well.
:-)
 
- And finally modular "emulation" - it would be possible to recompile individual
.dll to another os.
 
Side effects would be:
 
- More difficult to debug - since mapping to original binary image should be 
somehow
maintained - if register dump helps anyhow the developer.
 --
Have a nice day!
Tarmo.

Re: [Qemu-devel] Binary translation (of code)

[Richard Henderson]

On 05/10/2011 11:13 AM, Tarmo Pikaro wrote:
>> It would be much easier to ship an executable containing both the guest
>> application and qemu, so that executing it starts qemu with a
>> pre-defined configuration and runs the guest binary.
>  
> - Binary recompilation would allow faster execution than emulated code

Digital Equipment Corp (DEC) did a lot of work with static binary recompilation
in the early 1990's, converting VAX VMS applications to Alpha VMS. It's
quite possible to do if you spend enough time on it, and have a well
defined application environment.

That said, Hewlett Packard (HP) has done a very similar amount of work with
dynamic binary recompilation of PA-RISC HP/UX to IA-64 HP/UX, and achieved
similar results to what DEC achieved.

There has been a *lot* of papers about dynamic recompilation over the last
decade or two.  I believe that the general consensus is that -- with the
addition of dynamic profiling -- dynamic recompilation allows faster 
execution than static recompilation.

A lot of this is stuff that QEMU doesn't do. But the gist is, you add
profiling information to basic blocks as you translate them. This first
compilation pass is very quick and dirty, producing only moderately poor
translated code. As the program runs, a profile is collected that allows
the emulation environment to identify portions of the program that should
be compiled again, with much higher optimization. The thing that allows
this dynamic compilation to produce code that runs faster than static
compilation is that the VM can make simplifying assumptions about how a
portion of the program acts (either discovered from the profile, or a true
guess) and check those assumptions before the translated code is executed.
If the assumptions turn out to be invalid, then the VM can fall back to
the original quick compilation, or re-compile the portion of the program
without the assumptions.

If you're truly interested, a fair portion of these sorts of papers are
written in the context of Java Virtual Machines.  But the techniques apply
equally well to any dynamic compilation process.


r~


P.S: I seem to recall reading that HP had done some testing of their PA-RISC
dynamic recompiler, producing PA-RISC output too.  The recompiled programs
could then run on the same hardware as the original program.  The recompiled
programs ran faster than the originals, due to the techniques described.

Re: [Qemu-devel] Binary translation (of code)

[Lluís]

Tarmo Pikaro writes:
>> It would be much easier to ship an executable containing both the guest
>> application and qemu, so that executing it starts qemu with a
>> pre-defined configuration and runs the guest binary.
>
> - Binary recompilation would allow faster execution than emulated code

QEMU does precisely that, using a JIT. You wouldn't obtain much more
performance by generating a pre-translated binary instead of using
QEMU's JIT. And that's without taking into account the difficulties
associated with the static binary analysis that would be required (as
others have already pointed to you to in previous mails).


> - qemu constantly changes (based on amount of patches provided in this
> mail list) - in order to keep image+qemu working - simplest way is to convert 
> into
> executable. Btw - qemu could be used as a bootstrap to image as well.
> :-)

Maybe you didn't understand what I was saying. Think of it as a
self-extracting executable that contains both a specific qemu binary, as
well as the guest binary you want to execute. When you execute that
bundle, it transparently extracts both components (qemu + the guest
application) and starts qemu to execute that application.

Still, this is a poor approach from the software maintenance point of
view, and falls into the kind of strategies that windows application
developers use (bundle private copies of each library the application is
going to use).


> - And finally modular "emulation" - it would be possible to recompile individual
> .dll to another os.

I suppose you meant another architecture, as recompiling to another OS
makes no sense on the general case (can have a completely different set
of syscalls).

Still, I don't see the point of translating a single library instead of
the whole application (specially when you have access to a library
compiled for you target architecture, or even better access to the
source code to compile that library to whatever target you desire).


> Side effects would be:
>
> - More difficult to debug - since mapping to original binary image should be 
> somehow
> maintained - if register dump helps anyhow the developer.

As others have told you, qemu already has an interface to allow gdb to
debug the guest application.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

[Qemu-devel] Binary translation (of code)

[Tarmo Pikaro]

Hi !

I've analyzed quite a lot of emulators source code, including qemu as well.

But I somehow would like to completely get rid of emulators, and simply convert
application from one cpu/board to another cpu/board.

On wiki pages this is called "binary translation".

- Do you know some open source code projects related to binary translation ?

I'm searching for enthusiasts / gurus who want / could be involved in this 
excersise as well.

My intrest also goes beoynd one windows - linux - I would like to 
binary translate also
older console games - like nintendo/super nintendo rom (directly to .exe).

I was thinking about starting from qemu and cracking it into correct direction - 

has anyone ever tried to:

- put qemu in visual studio (or other ide where it can be debugged)
- cross compiled qemu with cygwin ?
 --
Have a nice day!
Tarmo.

Re: [Qemu-devel] Binary translation (of code)

[Mulyadi Santosa]

Hi...

On Sat, May 7, 2011 at 18:26, Tarmo Pikaro <tapika@yahoo.com> wrote:
> Hi !
>
> I've analyzed quite a lot of emulators source code, including qemu as well.
>
> But I somehow would like to completely get rid of emulators, and simply convert
> application from one cpu/board to another cpu/board.
>
> On wiki pages this is called "binary translation".
>
> - Do you know some open source code projects related to binary translation ?

Well, you end up in that kind of project, which is Qemu :)
specifically the TCG (Tiny Code Generator) part....

> has anyone ever tried to:
>
> - put qemu in visual studio (or other ide where it can be debugged)

AFAIK, folks here use gdb or its interface such as ddd, but I might be
wrong....

> - cross compiled qemu with cygwin ?

AFAIK too, folks uses mingw here...

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Re: [Qemu-devel] Binary translation (of code)

[Blue Swirl]

On Sat, May 7, 2011 at 2:26 PM, Tarmo Pikaro <tapika@yahoo.com> wrote:
> Hi !
>
> I've analyzed quite a lot of emulators source code, including qemu as well.
>
> But I somehow would like to completely get rid of emulators, and simply convert
> application from one cpu/board to another cpu/board.
>
> On wiki pages this is called "binary translation".
>
> - Do you know some open source code projects related to binary translation ?
>
> I'm searching for enthusiasts / gurus who want / could be involved in this
> excersise as well.
>
> My intrest also goes beoynd one windows - linux - I would like to
> binary translate also
> older console games - like nintendo/super nintendo rom (directly to .exe).

In general, this is not possible. Consider for example self-modifying
or otherwise dynamically created code, or just code that examines
itself.

In some specific trivial cases it could work, and QEMU could be made
to abort if translation would be needed.

[Qemu-devel] Binary translation (of code)

[Tarmo Pikaro]

> In general, this is not possible. Consider for example self-modifying
> or otherwise dynamically created code, or just code that examines
> itself.

> In some specific trivial cases it could work, and QEMU could be made
> to abort if translation would be needed.

I think self-modifying code is kinda rare case - it's made typically for
protection againt hackers , and typically on pc side. Nintendo roms probably 
don't use this kind of
protection.

Anyway - I think even to self-modifying code could be some tricks like 
dynamically generated code.

I would be probably intrest to re-compile only modules, like .dll - but this 
would 

require to analyze when and how .dll being loaded. This is kinda self-modifying 
code as well ? (OS loads .DLL)

 --
Have a nice day!
Tarmo.

Re: [Qemu-devel] Binary translation (of code)

[Blue Swirl]

On Sun, May 8, 2011 at 4:05 PM, Tarmo Pikaro <tapika@yahoo.com> wrote:
>
>> In general, this is not possible. Consider for example self-modifying
>> or otherwise dynamically created code, or just code that examines
>> itself.
>
>> In some specific trivial cases it could work, and QEMU could be made
>> to abort if translation would be needed.
>
> I think self-modifying code is kinda rare case - it's made typically for
> protection againt hackers , and typically on pc side. Nintendo roms probably
> don't use this kind of
> protection.

It doesn't have to be protection, for example GCC generates
trampolines to stack when using nested functions.

> Anyway - I think even to self-modifying code could be some tricks like
> dynamically generated code.

It would be possible to save the original executable (for read
references or write references to code that change already generated
code) and invoke translator when we detect untranslated instructions.
This would amount to a full QEMU plus some kind of startup cache.

> I would be probably intrest to re-compile only modules, like .dll - but this
> would
>
> require to analyze when and how .dll being loaded. This is kinda self-modifying
> code as well ? (OS loads .DLL)

In general, a program can load anything and start executing them or
even modify previously non-executable region to become executable.

Re: [Qemu-devel] Binary translation (of code)

[Stefan Hajnoczi]

On Sun, May 8, 2011 at 2:46 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Sun, May 8, 2011 at 4:05 PM, Tarmo Pikaro <tapika@yahoo.com> wrote:
>>
>>> In general, this is not possible. Consider for example self-modifying
>>> or otherwise dynamically created code, or just code that examines
>>> itself.
>>
>>> In some specific trivial cases it could work, and QEMU could be made
>>> to abort if translation would be needed.
>>
>> I think self-modifying code is kinda rare case - it's made typically for
>> protection againt hackers , and typically on pc side. Nintendo roms probably
>> don't use this kind of
>> protection.
>
> It doesn't have to be protection, for example GCC generates
> trampolines to stack when using nested functions.

An example related to console games is that Gameboy games copy some
routines into RAM and jump into them during one phase of the screen
refresh because of hardware limitations.  I forget the details but I
think you cannot access ROM during some part of the screen refresh,
even for code execution.  This would break if you statically
translated the ROM.  Console games do whacky things.

Stefan

Re: [Qemu-devel] Binary translation (of code)

[Tarmo Pikaro]

Hi !

> > I think self-modifying code is kinda rare case - it's made typically for
> > protection againt hackers , and typically on pc side. Nintendo roms probably
> > don't use this kind of
> > protection.
> 
> It doesn't have to be protection, for example GCC generates
> trampolines to stack when using nested functions.

Ok, so apparently we will have some challenges on the way.

I guess some sort of mutation - qemu + recompiler could be done as well...


Debugger: can gdb be used in windows as well ?
I think I have tried ddd in cygwin, it was kinda slow and diffucult to use.

Re: [Qemu-devel] Binary translation (of code)

[Lluís]

Tarmo Pikaro writes:

> Hi !
>> > I think self-modifying code is kinda rare case - it's made typically for
>> > protection againt hackers , and typically on pc side. Nintendo roms probably
>> > don't use this kind of
>> > protection.
>> 
>> It doesn't have to be protection, for example GCC generates
>> trampolines to stack when using nested functions.

> Ok, so apparently we will have some challenges on the way.

> I guess some sort of mutation - qemu + recompiler could be done as well...

It would be much easier to ship an executable containing both the guest
application and qemu, so that executing it starts qemu with a
pre-defined configuration and runs the guest binary.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth