Re: [Qemu-devel] [HelenOS-devel] [sparc64] Miscomputed minimum of a group of numbers in sparc64 emulation

[Artyom Tarasenko]

On Fri, Jul 1, 2011 at 11:36 AM, Jakub Jermar <address@hidden> wrote:
> 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.

Looks like it's a pretty nice test case.

The test case scenario is to load the initial values into the
registers (you already know them),
calculate the mins, cmp the result with expected and jump somewhere.
Since it happens with interrupts disabled, we don't need an OS or bios
to test that. The binary just has to have an entry point at 0x20,
then we can load it instead of bios.

Care to produce the test case? (Otherwise I'll do it, but probably not
until the weekend after the next one).

> 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.

Yes, I think this the way stepi  works.

> Jakub
>
> _______________________________________________
> HelenOS-devel mailing list
> address@hidden
> http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
>



-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/