From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qca9U-00026B-8N for qemu-devel@nongnu.org; Fri, 01 Jul 2011 05:36:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qca9S-0000P6-IH for qemu-devel@nongnu.org; Fri, 01 Jul 2011 05:36:43 -0400 Received: from mx2.avast.com ([91.213.143.6]:48552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qca9R-0000P0-Sl for qemu-devel@nongnu.org; Fri, 01 Jul 2011 05:36:42 -0400 Message-ID: <4E0D9527.7010106@jermar.eu> Date: Fri, 01 Jul 2011 11:36:39 +0200 From: Jakub Jermar MIME-Version: 1.0 References: <4E0CE6A7.10901@jermar.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [HelenOS-devel] [sparc64] Miscomputed minimum of a group of numbers in sparc64 emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: HelenOS development mailing list Cc: qemu-devel@nongnu.org Hi Artyom, On 1.7.2011 11:15, Artyom Tarasenko wrote: > Hi Jakub, > 2011/6/30 Jakub Jermar : >> Hi, >> >> we have been observing a problem with HelenOS running on the latest git >> Qemu/sparc64. The gist of the problem is that the following computation >> of minimum of 64 and 512 surprisingly gives 512: >> >> bytes = min(len, BPS(bs) - pos % BPS(bs)); >> bytes = min(bytes, nodep->size - pos); >> >> On input, `len` is 64, `pos` is 0, `BPS(bs)` is 512 and `nodep->size` is >> some bigger number. Surprisingly, in a non-single-stepping mode, Qemu >> computes `bytes` as 512 instead of 64. > > How is did you manage to see "bytes" without GDB? > In my case, as reported, a printf or any other statement using bytes > was simply not reached. I just added a printf of all the variables in play after the computation of the second min(). In my case, bytes was printed as the fourth number (i.e. fifth argument to printf()). This modification of the code, as you pointed out on our ML, reproduces the error on the first invocation of the function, otherwise the bug seems to show later. >> When singlestepping via GDB, the >> result is correct. > > You mean singlestepping gives other result than just setting a > breakpoint at target address? Yes, even though I tried singlestepping just once. > And just to clarify, with 'singlestepping' do you mean manual stepping > through the code, or the '-singlestep' qemu option? Should have been clearer on this - I meant putting a GDB breakpoint to the first `cmp` instruction in the block at 0x67c8 and then doing `stepi` all the way down beoynd the second `movgu` instruction at 0x6808. In this case, the condition code register was computed properly. On the other hand, putting a breakpoint directly to the secnod `movgu` at 0x6808 showed me the unexpected value in ccr and the behavior was the same as if no breakpoint was placed at all. I would imagine that when singlestepping using GDB's `stepi`, Qemu would throw away the large block and create a separate block for each instruction, but this is just a bloody guess of mine. Jakub