----- Original Message ----- > From: "Alessandro Di Federico" <ale+q...@clearmind.me> > To: "Paolo Bonzini" <pbonz...@redhat.com>, "Liviu Ionescu" <i...@livius.net> > Cc: "qemu-devel" <qemu-devel@nongnu.org> > 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 <pbonz...@redhat.com> 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
