From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DPIuX-0003ws-K3 for qemu-devel@nongnu.org; Sat, 23 Apr 2005 07:34:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DPIuW-0003wS-2Q for qemu-devel@nongnu.org; Sat, 23 Apr 2005 07:34:57 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DPIuV-0003t0-Vl for qemu-devel@nongnu.org; Sat, 23 Apr 2005 07:34:56 -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 1DPIw7-0001wo-6C for qemu-devel@nongnu.org; Sat, 23 Apr 2005 07:36:35 -0400 From: Paul Brook Subject: Re: [Qemu-devel] X86_64 (AMD64) build segfaults Date: Sat, 23 Apr 2005 12:33:37 +0100 References: <20050421163413.37378212@smirftschs.home.tld> <200504221733.25275.paul@codesourcery.com> <20050423110513.423af760@smirftschs.home.tld> In-Reply-To: <20050423110513.423af760@smirftschs.home.tld> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504231233.38717.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: qemu-devel@nongnu.org On Saturday 23 April 2005 10:05, developer@isl-gbr.de wrote: > does this mean this problem is currently not fixable (and maybe "never" - > in a considerable amount of time will ?) Correct. It may be fixable, but there's basically zero interest in fixing it. Qemu is pretty much the only place where this particular behaviour (a single ret at the end of the code) is required or even desirable. In fact the opposite is usually true - you want the fast path to be as short as possible for better cache locality. IMHO the way forward long-term is to implement some sort of code generation in qemu. By this I mean incorporating some sort of compiler backend/optimizing assembler into qemu, not just writing op.c in assembly. Obviously this is a large chunk of work. Paul