[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: Alessandro Di Federico
Subject: Re: [Qemu-devel] Support for using TCG frontend as a library
Date: Thu, 1 Dec 2016 00:01:12 +0100

On Tue, 29 Nov 2016 17:26:59 +0100
Paolo Bonzini <address@hidden> wrote:

> 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.

Does QEMU already have some mechanism to generate code? Otherwise I can
try to factor out the enum in a file that can be included in multiple

> 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.

My idea was to offer it externally, if available, more for debugging
purposes than for actual usage, in a "best-effort" way, let's say.
Isolating the backend too makes sense, but I'm not sure how much
interest there is on this, I'll first focus on exposing the frontends,
which is the killer feature for many of us.

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

This is something I didn't think about, it might be interesting indeed.
But why only linux-user and not full system emulation too?

> 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).

If most how the new helpers will be pure it might make sense to make a
one-time effort to annotate existing helpers with the list of parts of
the CPU they might access. I currently have an LLVM pass which analyzes
the helpers and collect programmatically this information. This might
be used for an initial collection of such information, or maybe even
run periodically (before each release?).

However, I'd leave discussion for this things for later. In the coming
weeks I'll try to come up with some self-contained patches for review.

On Tue, 29 Nov 2016 18:55:24 +0200
Liviu Ionescu <address@hidden> wrote:

> if you manage to make the TCG frontend as a library, it would be
> great to check that it can also be used from C++.
> the current QEMU headers prevent this, by using C++ reserved words
> (like `class`), which is a real pity.

I'm already using it from C++ (see rev.ng)! Users only need to include
ptc.h, nothing else.

Thanks for your responses, expect patches.

Alessandro Di Federico
PhD student at Politecnico di Milano

reply via email to

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