From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCN4I-0007YK-BK for qemu-devel@nongnu.org; Thu, 01 Dec 2016 03:50:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCN4F-0007mr-NN for qemu-devel@nongnu.org; Thu, 01 Dec 2016 03:50:14 -0500 Received: from mx6-phx2.redhat.com ([209.132.183.39]:48314) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cCN4F-0007lc-Et for qemu-devel@nongnu.org; Thu, 01 Dec 2016 03:50:11 -0500 Date: Thu, 1 Dec 2016 03:50:01 -0500 (EST) From: Paolo Bonzini Message-ID: <1881805253.931387.1480582201178.JavaMail.zimbra@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Support for using TCG frontend as a library List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alessandro Di Federico Cc: Liviu Ionescu , qemu-devel ----- Original Message ----- > From: "Alessandro Di Federico" > To: "Paolo Bonzini" , "Liviu Ionescu" > Cc: "qemu-devel" > 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 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