From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ic0ym-0006SV-Vo for qemu-devel@nongnu.org; Sun, 30 Sep 2007 11:45:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ic0yk-0006RH-J7 for qemu-devel@nongnu.org; Sun, 30 Sep 2007 11:45:11 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ic0yk-0006R8-DQ for qemu-devel@nongnu.org; Sun, 30 Sep 2007 11:45:10 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ic0yj-0000WY-TD for qemu-devel@nongnu.org; Sun, 30 Sep 2007 11:45:10 -0400 Received: by nf-out-0910.google.com with SMTP id 30so2574118nfu for ; Sun, 30 Sep 2007 08:45:09 -0700 (PDT) Message-ID: Date: Sun, 30 Sep 2007 18:45:08 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] target_mmap and host vs target page sizes. In-Reply-To: <20070930114734.GE19016@edgar.underground.se.axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070930011817.GA19016@edgar.underground.se.axis.com> <20070930095320.GD19016@edgar.underground.se.axis.com> <20070930114734.GE19016@edgar.underground.se.axis.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 9/30/07, Edgar E. Iglesias wrote: > With this updated patch, I can now reliably run statically linked sparc64 programs on my 32 bit host. Dynamically linked sparc64 programs reliably fail with an unhandled trap 0x37. qemu m68k reliably segfaults with and without the patch. Again, I tested CRIS and MIPS 8K and they both reliably manage to load and run my programs. I also ran some arm (4K pages) programs, which worked fine. 0x37 is TT_PRIV_ACT, taken when privileged instructions are executed in unprivileged mode. Could you try running this program again with -d in_asm,op and see what is the faulting instruction and the generated ops? Maybe some instruction has too strict checks.