From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19OxLA-0003dW-QL for qemu-devel@nongnu.org; Sun, 08 Jun 2003 06:23:56 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19OxL5-0003W8-8n for qemu-devel@nongnu.org; Sun, 08 Jun 2003 06:23:51 -0400 Received: from pizda.ninka.net ([216.101.162.242]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OxKr-00030g-1B for qemu-devel@nongnu.org; Sun, 08 Jun 2003 06:23:37 -0400 Date: Sun, 08 Jun 2003 03:20:40 -0700 (PDT) Message-Id: <20030608.032040.08328976.davem@redhat.com> Subject: Re: [Qemu-devel] Sparc port From: "David S. Miller" In-Reply-To: <3EE30B8E.5070600@free.fr> References: <3EE30B8E.5070600@free.fr> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , To: qemu-devel@nongnu.org, fabrice.bellard@free.fr From: Fabrice Bellard Date: Sun, 08 Jun 2003 12:10:22 +0200 I have two ideas : 1) We use -mflat for exec-i386.c and helper-i386.c but not for op-i386.c to avoid gcc bugs. Now that op-i386.c only contains opcodes, the code inside should almost look like '-mflat' code. -mflat doesn't work, gcc doesn't obey -fno-delayed-branch when -mflat is specified and that basically makes it useless. Also, this feature of GCC is scheduled for deprecation. 2) We can patch cpu_exit_loop() by doing the right number of restores (maybe a single longjmp would suffice as l0...l7 are still saved. This might work. I think all things that generated code could call should marked as ONLY being invoked from generated code, and furthermore have a very fixed environment that we can rely upon. It is the only clean way to deal with this sparc issue in the long term.