From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DYVcG-00043l-Q8 for qemu-devel@nongnu.org; Wed, 18 May 2005 16:58:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DYVcF-00043J-P2 for qemu-devel@nongnu.org; Wed, 18 May 2005 16:58:07 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DYVV6-0000RY-4D for qemu-devel@nongnu.org; Wed, 18 May 2005 16:50:44 -0400 Received: from [65.74.133.9] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DYVbO-0003lA-Ho for qemu-devel@nongnu.org; Wed, 18 May 2005 16:57:15 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [patch] gcc4 host support Date: Wed, 18 May 2005 21:48:50 +0100 References: <200505112204.10204.paul@codesourcery.com> <20050518100634.GC30476@MAIL.13thfloor.at> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505182148.50628.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jhoger@pobox.com Cc: David Woodhouse , qemu-devel@nongnu.org On Wednesday 18 May 2005 20:29, John Hogerhuis wrote: > This all feels wrong in general. The changes should either be adding > some facility to gcc which permits QEMU to use it in this way (gcc is > an open source project after all, so it's at least a possibility), Are you willing to write and maintain the gcc patches necessary to do this? qemu is pretty much the only think that has this particular set of requirelents (the return instruction must be the last instruction in the function). The fact is qemu is abusing the output of gcc in ways that were never guaranteed to work. > or we should generate the dynamic code generator once with whatever > version of GCC and make that part of the build, perhaps even letting > it diverge (i.e. add enhancements/optimizations directly to the > generated assembly). IMHO That's not really an option. The whole point of dyngen is to avoid having to write and maintain big chunks of assembly for every single target. It's been said before that the long-term solution is to [incrementally] remove dyngen altogether, and replace it with a had-written code generator. I've discussed this in a bit more detail with Fabrice, and have an almost-working prototype implementation. When I get something that actually works I'll post it to the list for comments. Paul