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

[Paolo Bonzini]

----- Original Message -----
> From: "Alessandro Di Federico" <address@hidden>
> To: "Paolo Bonzini" <address@hidden>, "Liviu Ionescu" <address@hidden>
> Cc: "qemu-devel" <address@hidden>
> Sent: Thursday, December 1, 2016 12:01:12 AM
> Subject: Re: [Qemu-devel] Support for using TCG frontend as a library
> 
> 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
> places.

If you count scripts/shaderinclude.pl, scripts/feature_to_c.sh and
the like, yes.  The biggest is probably tracetool.  It's ad hoc.

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

Yes, of course.

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

It would simplify the library.  The front-end and helpers have some differences
between usermode and softmmu, and the latter is much more intertwined with
the rest of the QEMU infrastructure (MMU indices, limits on multi-page
translations, etc.)

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

It can also be used to guide the conversion to pure helpers, I guess.
For example, helpers such as helper_divb_AL should definitely get and
return globals instead of reading/writing to CPUX86State (in the specific
case of division, of course they would keep the side effects because they
can raise a division by zero exception).

Paolo