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 19Oxnd-0001u9-1p for qemu-devel@nongnu.org; Sun, 08 Jun 2003 06:53:21 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19OxnW-0001cq-7L for qemu-devel@nongnu.org; Sun, 08 Jun 2003 06:53:16 -0400 Received: from smtp5.wanadoo.fr ([193.252.22.27] helo=mwinf0403.wanadoo.fr) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OxnT-0001Uh-0G for qemu-devel@nongnu.org; Sun, 08 Jun 2003 06:53:11 -0400 Received: from free.fr (unknown [81.48.134.159]) by mwinf0403.wanadoo.fr (SMTP Server) with ESMTP id 07D3C50002EE for ; Sun, 8 Jun 2003 12:53:09 +0200 (CEST) Message-ID: <3EE3158B.5090901@free.fr> Date: Sun, 08 Jun 2003 12:52:59 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] Sparc port References: <3EE30B8E.5070600@free.fr> <20030608.032040.08328976.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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 David S. Miller wrote: > 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. My suggestion was to use it without -fno-delayed-branch: only the helpers and exec-i386.c would be compiled with it. op-i386.c would still stay in no-flat mode. > Also, this feature of GCC is scheduled for deprecation. OK. This is a good reason for not using it ! > 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. I am trying to do that. In the long term, maybe a proper code generator will be used, but the function helpers will stay the same, so we must find a good solution for them. > It is the only clean way to deal with this sparc issue in the long > term. I still have a problem: if a helper function modifies an x86 register which is in a sparc register (say EAX in %l0), then it cannot work because save/restore are done at the beginning of the helper. BTW, another question: how can we know on Sparc if a SIGSEGV or SIGBUS was generated because of a read or a write ? The Linux kernel has the info but it does not seem to be copied to user space. It may be interesting to find a standard way to indicate if it is a read or write which caused the fault (using a field in siginfo_t would be nice). Fabrice.