From: Jakub Jermar <jakub@jermar.eu>
To: HelenOS development mailing list <helenos-devel@lists.modry.cz>
Cc: qemu-devel@nongnu.org
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 [thread overview]
Message-ID: <4E0D9527.7010106@jermar.eu> (raw)
In-Reply-To: <CACXAS8DixKjzQxrjDGwj-xzs9ZxN=O9P=sqN5d9Htx7PNngtNA@mail.gmail.com>
Hi Artyom,
On 1.7.2011 11:15, Artyom Tarasenko wrote:
> Hi Jakub,
> 2011/6/30 Jakub Jermar <jakub@jermar.eu>:
>> 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
next prev parent reply other threads:[~2011-07-01 9:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 21:12 [Qemu-devel] [sparc64] Miscomputed minimum of a group of numbers in sparc64 emulation Jakub Jermar
2011-07-01 9:15 ` [Qemu-devel] [HelenOS-devel] " Artyom Tarasenko
2011-07-01 9:36 ` Jakub Jermar [this message]
2011-07-01 10:41 ` Artyom Tarasenko
2011-07-01 12:57 ` Jakub Jermar
2011-07-01 14:11 ` Jakub Jermar
2011-07-01 14:24 ` Laurent Desnogues
2011-07-01 14:28 ` Jakub Jermar
2011-07-01 15:08 ` Artyom Tarasenko
2011-07-01 14:15 ` Laurent Desnogues
2011-07-01 14:21 ` Jakub Jermar
2011-07-01 15:03 ` Artyom Tarasenko
2011-07-01 15:20 ` Laurent Desnogues
2011-07-01 15:53 ` Artyom Tarasenko
2011-07-01 16:14 ` Artyom Tarasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E0D9527.7010106@jermar.eu \
--to=jakub@jermar.eu \
--cc=helenos-devel@lists.modry.cz \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).