qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [HelenOS-devel] [sparc64] Miscomputed minimum of a grou


From: Jakub Jermar
Subject: Re: [Qemu-devel] [HelenOS-devel] [sparc64] Miscomputed minimum of a group of numbers in sparc64 emulation
Date: Fri, 01 Jul 2011 11:36:39 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11

Hi Artyom,

On 1.7.2011 11:15, Artyom Tarasenko wrote:
> Hi Jakub,
> 2011/6/30 Jakub Jermar <address@hidden>:
>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]