From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DP1FG-0008Cb-E5 for qemu-devel@nongnu.org; Fri, 22 Apr 2005 12:43:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DP1FD-0008BL-4k for qemu-devel@nongnu.org; Fri, 22 Apr 2005 12:43:09 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DP1FC-00080W-Ke for qemu-devel@nongnu.org; Fri, 22 Apr 2005 12:43:06 -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 1DP18l-000113-4S for qemu-devel@nongnu.org; Fri, 22 Apr 2005 12:36:27 -0400 From: Paul Brook Subject: Re: [Qemu-devel] X86_64 (AMD64) build segfaults Date: Fri, 22 Apr 2005 17:33:25 +0100 References: <20050421163413.37378212@smirftschs.home.tld> <20050422174131.779509e3@smirftschs.home.tld> <8737c432399be6c4c8b349c300916cd8@elis.ugent.be> In-Reply-To: <8737c432399be6c4c8b349c300916cd8@elis.ugent.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504221733.25275.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 Friday 22 April 2005 17:12, Jonas Maebe wrote: > On 22 apr 2005, at 17:41, developer@isl-gbr.de wrote: > > Hello Jonas, here is the output of the command you gave me for this > > function, does this help ? > > It helps in the sense that it confirms my suspicion, although I don't > know why it creates such convoluted code. Maybe in order to have as > small code as possible with at the same time as many aligned jump > targets as possible. It's definitely not trivial to parse this, and > even less trivial to rewrite it so it is usable for qemu's purposes (in > this particular case, the retq could be replaced by a jmp, but you > can't count on there being 4 padding bytes after each ret). > > You (or someone else) will have to find a way to force gcc 4.0 to put > one ret (or jump) at the very end of the code it generates. If that's > not possible, it will be quite hard to support gcc 4.0 in qemu... It's not possible to force gcc4 to put the "ret" at the end of the code. Paul