From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZA3d-00082M-DE for qemu-devel@nongnu.org; Fri, 29 Aug 2008 15:54:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZA3Y-0007xf-19 for qemu-devel@nongnu.org; Fri, 29 Aug 2008 15:54:53 -0400 Received: from [199.232.76.173] (port=40777 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZA3W-0007we-K5 for qemu-devel@nongnu.org; Fri, 29 Aug 2008 15:54:50 -0400 Received: from yw-out-1718.google.com ([74.125.46.156]:39799) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZA3V-0005zi-Pc for qemu-devel@nongnu.org; Fri, 29 Aug 2008 15:54:50 -0400 Received: by yw-out-1718.google.com with SMTP id 6so74730ywa.82 for ; Fri, 29 Aug 2008 12:54:49 -0700 (PDT) Message-ID: Date: Fri, 29 Aug 2008 22:54:48 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [sparc64] qemu crashes after the "OpenBIOS for Sparc64" banner is printed In-Reply-To: <200808292022.46951.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48B6A035.2090105@jermar.eu> <200808292022.46951.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: Paul Brook Cc: Jakub Jermar , qemu-devel@nongnu.org On 8/29/08, Paul Brook wrote: > > Surprisingly it was moving of do_interrupt to helper.c that caused the > > bug. Moving it back to op_helper.c allows Sparc64 to boot. I'm still > > trying to understand the real cause of the bug and to find if there is > > some other way of fixing this. This kind of voodoo makes me nervous. > > > do_interrupt calls change_pstate, which relies on global register state. > Global register state is only valid when called directly from translated code > or other code that includes exec.h. > > You should never call code in op_helper.c from outside that file (or > cpu-exec.h). The easy way to enforce this is to put teh declarations for > functions defined in op_helper.h in exec.h, not helper.h or cpu.h. Failure to > follow this rule results in bugs like the one you've encountered. > > helper.h is included multiple times, so should really just contain DEF_HELPER > statements. Thanks, great advice. I'll check all exported functions.