From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CwQmO-00016l-Uy for qemu-devel@nongnu.org; Wed, 02 Feb 2005 15:07:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CwQmN-00016Z-C6 for qemu-devel@nongnu.org; Wed, 02 Feb 2005 15:07:12 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwQco-0007mq-TW for qemu-devel@nongnu.org; Wed, 02 Feb 2005 14:57:19 -0500 Received: from [65.74.133.9] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CwPzt-00013B-Dz for qemu-devel@nongnu.org; Wed, 02 Feb 2005 14:17:05 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Armv5 target Date: Wed, 2 Feb 2005 19:17:01 +0000 References: <200501312019.45282.paul@codesourcery.com> <200502021547.24944.paul@codesourcery.com> <200502021918.47411.uli@suse.de> In-Reply-To: <200502021918.47411.uli@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502021917.02193.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 > > I've attached two programs. segv-test.c tests for the kernel bug. > > This program hangs in an endless segfault loop when I run it in qemu-arm. > The kernel version does not seem to matter here, I have tried 2.6.11, > 2.6.5 and 2.4.21. Has anybody ever observed this and/or knows what it is > caused by? (The test works fine on i386 and on a real ARM machine.) The host kernel bug seems specific to this particular kernel. I've tried other 2.6.9 kernels on different machines, and a 2.6.10 kernel on this machine, and they all work ok. I guess it's a fluke miscompilation or something. The reason it goes into an infinite loop when run under qemu is as follows: The generated code causes a segfault trying to write to protected memory. On a real machine the signal handler unprotects the memory, and keeps going. Inside qemu the host signal handler just queues the target signal. For most signals this is ok; the target handler will be invoke at the end of the TB. However in this case we need to run the target handler immediately, otherwise the segv will occur again when we try and continue. I think fixing this requires executing the target signal handler code from within the host signal handler. As an added complication we only want to do this for signals received while executing target code. Paul