[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Support for using TCG frontend as a library

From: Paolo Bonzini
Subject: Re: [Qemu-devel] Support for using TCG frontend as a library
Date: Tue, 29 Nov 2016 17:26:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 27/11/2016 20:32, Alessandro Di Federico wrote:
> I've been investigating the needs of the various projects that might be
> interested in using it and they sum up to the following:
> * Be able to load in the same process multiple libtcg-$ARCH.so for
>   different architectures.
> * Obtain the TCG instructions from code in a memory buffer.
> * Dump the assembly code of the code in a memory buffer.
> * Dump the TCG instructions in textual form.
> For what concerns helpers, it would be nice to have some metadata about
> them, for instance the parts of the CPU state they can change. It would
> also be nice to have a build configuration which produces a library
> containing all the helpers ready to be used, or, even better, a library
> as LLVM bitcode, which can then be further processed/analyzed.
> Here you can find some relevant parts of my draft implementation part
> of rev.ng:
> * The interface exposed to users:
>   https://polimicg.org/gitlab/revng/qemu/blob/develop/linux-user/ptc.h
> * Implementation of the interface functions:
>   https://polimicg.org/gitlab/revng/qemu/blob/develop/linux-user/ptc.c
> * For the changes introduced elsewhere look for CONFIG_LIBTINYCODE:
> https://polimicg.org/gitlab/search?utf8=%E2%9C%93&search=CONFIG_LIBTINYCODE&group_id=&project_id=83&search_code=true&repository_ref=develop

It's pretty clean!  I would rather avoid the duplicate enums, possibly
by automatically generating large parts of ptc.h, but that's pretty much
it.  I see that you check that the constants match (that cpp stuff is
disgusting :)), and that is already a good thing.

As to dumping the assembly code, I think that's beyond the scope of
QEMU---rather, if there is an existing library to do so, QEMU would like
to use it because currently we're stuck with an old GPLv2-compatible
version of GNU binutils.  For everything else it makes sense to use a
"librarified" QEMU frontend and even backend.

It would even be better, I think, to make linux-user a client of the
library itself, because this will prevent bitrot.

As to the helpers, QEMU has annotations of helpers that read globals,
write globals or have side effects.  However, they are pretty new so
they aren't used too much.  In general we prefer new helpers to be pure,
but this is not true of much legacy code that dates back to even before
TCG (i.e. ~2008).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]