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