From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HD6oD-0000Os-K1 for qemu-devel@nongnu.org; Fri, 02 Feb 2007 17:23:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HD6oB-0000Og-6p for qemu-devel@nongnu.org; Fri, 02 Feb 2007 17:23:04 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HD6oB-0000Od-1W for qemu-devel@nongnu.org; Fri, 02 Feb 2007 17:23:03 -0500 Received: from phoenix.bawue.net ([193.7.176.60] helo=mail.bawue.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HD6oA-0005nt-N0 for qemu-devel@nongnu.org; Fri, 02 Feb 2007 17:23:02 -0500 Date: Fri, 2 Feb 2007 22:24:28 +0000 From: Thiemo Seufer Subject: Re: [Qemu-devel] Re: strange crash on FreeBSD-current/amd64 (pointer truncation?) Message-ID: <20070202222428.GA9622@networkno.de> References: <20070124200019.GA36641@saturn.kn-bremen.de> <20070201200030.GA68583@saturn.kn-bremen.de> <20070202040200.GA32244@networkno.de> <20070202214525.GA10125@saturn.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070202214525.GA10125@saturn.kn-bremen.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juergen Lock Cc: qemu-devel@nongnu.org Juergen Lock wrote: > > > Ok Jung-uk Kim found the following fix: (Thanx!) > > > > > > --- qemu/cpu-exec.c.orig Wed Jan 31 16:58:03 2007 > > > +++ qemu/cpu-exec.c Wed Jan 31 17:08:11 2007 > > > @@ -226,9 +226,9 @@ > > > > > > int cpu_exec(CPUState *env1) > > > { > > > - int saved_T0, saved_T1; > > > + long saved_T0, saved_T1; > > > #if defined(reg_T2) > > > - int saved_T2; > > > + long saved_T2; > > > > I used target_ulong instead. > > Isn't that 32 bit for 32 bit targets? Then it wouldn't fix the bug, > the problem happened for 32 bit guests (i386-softmmu) on 64 bit hosts > (FreeBSD-current/amd64), there the upper half of rbx which held a > pointer in the calling function was lost... Apparently I miss something here. If T0 is a (32bit) target_ulong, why does saving it to a (32bit) target_ulong and restoring it from there cause any trouble? Thiemo