From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cfh1q-00011w-O1 for qemu-devel@nongnu.org; Sat, 18 Dec 2004 11:01:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cfh1q-00011k-Ae for qemu-devel@nongnu.org; Sat, 18 Dec 2004 11:01:58 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cfh1q-00011h-6j for qemu-devel@nongnu.org; Sat, 18 Dec 2004 11:01:58 -0500 Received: from [38.113.2.101] (helo=rizzo.jerky.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cfgr3-0003ll-I2 for qemu-devel@nongnu.org; Sat, 18 Dec 2004 10:50:49 -0500 Received: from phreaker.net (kubrick.hotpop.com [38.113.3.103]) by rizzo.jerky.net (Postfix) with SMTP id 8250534AD0 for ; Sat, 18 Dec 2004 15:50:48 +0000 (UTC) Received: from jbrown.mylinuxbox.org (pcp03144805pcs.midval01.tn.comcast.net [68.59.228.236]) by smtp-1.hotpop.com (Postfix) with ESMTP id BBEB71A0157 for ; Sat, 18 Dec 2004 15:50:42 +0000 (UTC) Date: Sat, 18 Dec 2004 10:50:37 -0500 From: "Jim C. Brown" Subject: Re: [Qemu-devel] get_func() hangs with gcc 3.4.2 on MinGW and WinXP host Message-ID: <20041218155037.GA32132@jbrown.mylinuxbox.org> References: <20041215134754.GA28410@100tka.net> <20041215145903.GA29957@100tka.net> <20041215234503.GA12778@jbrown.mylinuxbox.org> <20041217195627.A38776@saturn.kn-bremen.de> <20041218040428.GA31934@jbrown.mylinuxbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041217195627.A38776@saturn.kn-bremen.de> 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 Sat, Dec 18, 2004 at 03:59:38PM +0100, Johannes Schindelin wrote: > Hi, > > On Fri, 17 Dec 2004, Jim C. Brown wrote: > > > On Sat, Dec 18, 2004 at 01:09:26AM +0100, Johannes Schindelin wrote: > > > Hi, > > > > > > it would be better to fix > > > the compilation of op.c, so that you really can chain the op_* functions. > > > What I mean: if you work on it, you could as well do it such that you gain > > > the most (performance) of it. > > > > > > Ciao, > > > Dscho > > > > > > > >From what I understand, this is outright impossible with later versions of > > gcc. In order to do what you want, you would have to write the code purely > > in assembler. > > What do new gcc's do? Why is it impossible to chain the code? Originally, the op_* functions for qemu were written so that they would have the machine code and then the rets at the very end of the function. qemu could then just chain them together by stripping the rets. gcc now rearranges the generated code around, and reserves the right to stick in extra rets any place it wants, not just the very end, which makes them very hard to strip off. I asked another developer about the difficulty of doing this, and was told that it would be easier to write a C compiler just for op.c from scratch. > Do you have > an example object file, or even better, an assembly snippet? Afraid not. > > Ciao, > Dscho > On Fri, Dec 17, 2004 at 07:56:27PM +0100, Juergen Lock wrote: > On Thu, Dec 16, 2004 at 01:37:53AM +0000, Johannes Schindelin wrote: > > Hi, > > > > On Wed, 15 Dec 2004, Jim C. Brown wrote: > > > > > This is due to a change in the way gcc compiles code ... 3.4.0 may work, > > > but later versions will cause functions to return prematurely (due to the way > > > qemu handles translated blocks). I suggested that a fix for this would be to > > > use function pointer calls instead of directly chaining machine code, but > > > apparently this is too slow to make qemu usable. > > > > The Forth way ;-) > >... > > How about instead post-processing the .s, replacing the rets with jumps > to the end of the function? Of course this part would be architecture > dependant (different assembler syntax), but other parts of qemu > are that as well, right? This may be possible. I don't know if the change applies to gcc only, in which case this is the best solution, or if it applies to gas as well, in which case this would solve nothing. Well, even if gas was changed, we could probably get around that by using a newer gcc with an older gas as the backend ... > > Just a thought... > Juergen > > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.