From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBSsf-0006P6-Br for qemu-devel@nongnu.org; Sat, 13 Dec 2008 06:41:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBSse-0006OX-BW for qemu-devel@nongnu.org; Sat, 13 Dec 2008 06:41:56 -0500 Received: from [199.232.76.173] (port=35596 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBSse-0006OQ-63 for qemu-devel@nongnu.org; Sat, 13 Dec 2008 06:41:56 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:52828) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBSsd-0004dT-G5 for qemu-devel@nongnu.org; Sat, 13 Dec 2008 06:41:55 -0500 Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate02.web.de (Postfix) with ESMTP id 83176F7A3F6C for ; Sat, 13 Dec 2008 12:41:54 +0100 (CET) Received: from [88.64.11.10] (helo=[192.168.1.198]) by smtp07.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1LBSsc-0005iU-00 for qemu-devel@nongnu.org; Sat, 13 Dec 2008 12:41:54 +0100 Message-ID: <49439F67.8070502@web.de> Date: Sat, 13 Dec 2008 12:41:27 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4938EA0D.7010004@web.de> <761ea48b0812130243u251cd765u2aaac271c50bf557@mail.gmail.com> In-Reply-To: <761ea48b0812130243u251cd765u2aaac271c50bf557@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5C63E0627071850655117A20" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: dyngen-exec.h vs. qemu-common.h Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5C63E0627071850655117A20 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Laurent Desnogues wrote: > On Fri, Dec 5, 2008 at 9:45 AM, Jan Kiszka wrote: >> right now dyngen-exec.h prevents that qemu-common.h (or other headers >> that drag in standard headers) can be included into all parts of qemu.= >> The reason for this is that dyngen-exec.h redefines a bunch of standar= d >> types, and that is likely due to >> >> [dyngen-exec.h:] >> /* NOTE: standard headers should be used with special care at this >> point because host CPU registers are used as global variables. Some >> host headers do not allow that. */ >> >> Trying to add the noreturn definition to a central place, I wonder now= >> if that comment will still be valid when we only have TCG archs, i.e. = if >> the successor of dyngen-exec.h could possibly become compatible with >> standard headers? Or what host headers on what host OS / distro are th= e >> precise problem that could survive the dyngen era? >=20 > Here is my understaning (to be taken with a grain of salt as I don't > know the dyngen era). >=20 > For dyngen some registers were globally allocated and great > care had to be taken where they are used so that they are not > used by included file (this can probably happen if you use some > standard header that inlines code). The files where this matters > are the one containing execution loop (cpu-exec.c) and the > one containing helper runtime that use the global registers > (op_helper.c). >=20 > Basically once all op_helper.c files which still contain references > to global registers are removed then we should be safe and > we'll be able to get rid of hostregs_helper.h. >=20 > As an example here is what the situation is for the ARM target: >=20 > - three global registers are used > * env is a global register that contains the address of the > CPU state > * T0 and T1 are two temporaries for parameter passing > and result returning in op_helper >=20 > - in op_helper you can see that env, T0 and T1 are used > (note that except for the 5 last helpers in that file, these > helpers don't really have to be here, passing them the env > as a parameter should be enough). >=20 > So if we want to get rid of dyngen-exec.h we have to remove > all references to global registers (and for the ARM target > that's not very difficult though a bit of a pain if you look at how > cpu_T0/T1 are used all over the place). To look for what > needs to be done you can start by looking for uses of > tcg_global_reg_new*. >=20 > Note that, on top of my lack of knowledge of dyngen, I don't > know system emulation so I may have missed some bits. >=20 > HTH, >=20 > Laurent Yeah, thanks. That gives confidence that I can install a workaround to cope with dyngen-exec.h dependencies for now and then look into overcoming them finally. Jan --------------enig5C63E0627071850655117A20 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAklDn2cACgkQniDOoMHTA+lujQCfXG/Gl0AvRIDjyBOEbtIQtoT8 M1MAoIByh6d3V9B7yNph+9mlm+nBCtDR =qcvG -----END PGP SIGNATURE----- --------------enig5C63E0627071850655117A20--