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

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

[Jakub Jermar]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

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. When singlestepping via GDB, the
result is correct.

I think this could be a bug in Qemu so I am attaching the relevant
portion of qemu.log with some comments and pointers in it.

I would appreciate if someone who understands the sparc64 code
translation could have a look at this. More debugging data may be
provided upon request.

Thanks,
Jakub

[-- Attachment #2: qemu.log --]
[-- Type: text/x-log, Size: 11032 bytes --]

IN: 
0x00000000000067a4:  ldub  [ %o0 + 0xb ], %g1
0x00000000000067a8:  sub  %i1, %i2, %i1
0x00000000000067ac:  ldub  [ %o0 + 0xc ], %g2
0x00000000000067b0:  sethi  %hi(0x1dc00), %o0
0x00000000000067b4:  sllx  %g1, 8, %g1
0x00000000000067b8:  ldx  [ %fp + 0x7ef ], %g3
0x00000000000067bc:  or  %o0, 0x258, %o0
0x00000000000067c0:  or  %g2, %g1, %g1
0x00000000000067c4:  sll  %g1, 0x10, %g1
0x00000000000067c8:  cmp  %i1, %g3
0x00000000000067cc:  srl  %g1, 8, %g4
0x00000000000067d0:  mov  %g3, %o3
0x00000000000067d4:  srl  %g1, 0x18, %g1
0x00000000000067d8:  or  %g4, %g1, %g4
0x00000000000067dc:  sllx  %g4, 0x30, %g2
0x00000000000067e0:  srlx  %g2, 0x30, %g2
0x00000000000067e4:  udivx  %i2, %g2, %g1
0x00000000000067e8:  mulx  %g1, %g2, %g1
0x00000000000067ec:  movgu  %xcc, %g3, %i1
0x00000000000067f0:  sll  %g4, 0x10, %g4
0x00000000000067f4:  sub  %i2, %g1, %g1
0x00000000000067f8:  srl  %g4, 0x10, %o1
0x00000000000067fc:  sub  %g2, %g1, %g1
0x0000000000006800:  sra  %o1, 0, %o1
0x0000000000006804:  cmp  %i1, %g1
0x0000000000006808:  movgu  %xcc, %g1, %i1	<= with 0 in %xcc the move is executed and overwrites 64 in %i1 by 512 from %g1
0x000000000000680c:  call  0x13f00		<= when I put breakpoint here, %xcc is 0 insted of 0b1001 in non-single-stepping mode
0x0000000000006810:  mov  %i1, %o4

OP after liveness analysis:
 movi_i64 tmp8,$compute_psr
 call tmp8,$0x0,$0
 ld_i64 tmp6,regwptr,$0x0
 movi_i64 tmp8,$0xb
 add_i64 loc5,tmp6,tmp8
 qemu_ld8u loc4,loc5,$0x0
 mov_i64 g1,loc4
 ld_i64 tmp7,regwptr,$0x88
 ld_i64 tmp6,regwptr,$0x90
 sub_i64 loc3,tmp7,tmp6
 st_i64 loc3,regwptr,$0x88
 ld_i64 tmp6,regwptr,$0x0
 movi_i64 tmp8,$0xc
 add_i64 loc5,tmp6,tmp8
 qemu_ld8u loc4,loc5,$0x0
 mov_i64 g2,loc4
 movi_i64 tmp8,$0x1dc00
 st_i64 tmp8,regwptr,$0x0
 movi_i64 tmp8,$0x8
 shl_i64 loc3,g1,tmp8
 mov_i64 g1,loc3
 ld_i64 tmp7,regwptr,$0xb0
 movi_i64 tmp8,$0x7ef
 add_i64 loc5,tmp7,tmp8
 qemu_ld64 loc4,loc5,$0x0
 mov_i64 g3,loc4
 ld_i64 tmp6,regwptr,$0x0
 movi_i64 tmp8,$0x258
 or_i64 loc3,tmp6,tmp8
 st_i64 loc3,regwptr,$0x0
 mov_i64 tmp6,g1
 or_i64 loc3,g2,tmp6
 mov_i64 g1,loc3
 movi_i64 tmp8,$0x10
 shl_i64 loc3,g1,tmp8
 mov_i64 g1,loc3
 ld_i64 tmp7,regwptr,$0x88
 mov_i64 cc_src,tmp7
 mov_i64 cc_src2,g3
 sub_i64 cc_dst,cc_src,cc_src2
 nopn $0x2,$0x2
 movi_i32 cc_op,$0x7
 movi_i64 tmp8,$0xffffffff
 and_i64 loc3,g1,tmp8
 movi_i64 tmp8,$0x8
 shr_i64 loc3,loc3,tmp8
 mov_i64 g4,loc3
 mov_i64 loc3,g3
 st_i64 loc3,regwptr,$0x18
 movi_i64 tmp8,$0xffffffff
 and_i64 loc3,g1,tmp8
 movi_i64 tmp8,$0x18
 shr_i64 loc3,loc3,tmp8
 mov_i64 g1,loc3
 mov_i64 tmp6,g1
 or_i64 loc3,g4,tmp6
 mov_i64 g4,loc3
 movi_i64 tmp8,$0x30
 shl_i64 loc3,g4,tmp8
 mov_i64 g2,loc3
 movi_i64 tmp8,$0x30
 shr_i64 loc3,g2,tmp8
 mov_i64 g2,loc3
 ld_i64 tmp6,regwptr,$0x90
 mov_i64 cc_src,tmp6
 mov_i64 cc_src2,g2
 movi_i64 tmp8,$0x0
 brcond_i64 cc_src2,tmp8,ne,$0x0
 movi_i32 tmp9,$0x28
 movi_i64 tmp8,$raise_exception
 call tmp8,$0x0,$0,tmp9
 set_label $0x0
 movi_i64 tmp8,$0x0
 divu2_i64 loc3,tmp8,cc_src,tmp8,cc_src2
 mov_i64 g1,loc3
 mul_i64 loc3,g1,g2
 mov_i64 g1,loc3
 nopn $0x3,$0x1,$0x3
 movi_i64 tmp10,$compute_psr
 call tmp10,$0x0,$0
 ext32u_i64 tmp0,xcc
 movi_i64 tmp10,$0x16
 shr_i64 tmp0,tmp0,tmp10
 movi_i64 tmp10,$0x1
 and_i64 tmp0,tmp0,tmp10
 ext32u_i64 tmp8,xcc
 movi_i64 tmp10,$0x14
 shr_i64 tmp8,tmp8,tmp10
 movi_i64 tmp10,$0x1
 and_i64 tmp8,tmp8,tmp10
 or_i64 tmp8,tmp8,tmp0
 movi_i64 tmp10,$0x1
 xor_i64 tmp8,tmp8,tmp10
 movi_i64 tmp10,$0x0
 brcond_i64 tmp8,tmp10,eq,$0x1
 mov_i64 tmp0,g3
 st_i64 tmp0,regwptr,$0x88
 set_label $0x1
 movi_i64 tmp8,$0x10
 shl_i64 loc3,g4,tmp8
 mov_i64 g4,loc3
 ld_i64 tmp6,regwptr,$0x90
 sub_i64 loc3,tmp6,g1
 mov_i64 g1,loc3
 movi_i64 tmp8,$0xffffffff
 and_i64 loc3,g4,tmp8
 movi_i64 tmp8,$0x10
 shr_i64 loc3,loc3,tmp8
 st_i64 loc3,regwptr,$0x8
 sub_i64 loc3,g2,g1
 mov_i64 g1,loc3
 ld_i64 tmp7,regwptr,$0x8
 movi_i64 tmp8,$0xffffffff
 and_i64 loc3,tmp7,tmp8
 ext32s_i64 loc3,loc3
 st_i64 loc3,regwptr,$0x8
 ld_i64 tmp6,regwptr,$0x88
 mov_i64 cc_src,tmp6
 mov_i64 cc_src2,g1
 sub_i64 cc_dst,cc_src,cc_src2
 mov_i64 loc3,cc_dst
 movi_i32 cc_op,$0x7
 nopn $0x3,$0x1,$0x3
 movi_i64 tmp10,$compute_psr
 call tmp10,$0x0,$0
 ext32u_i64 tmp0,xcc
 movi_i64 tmp10,$0x16
 shr_i64 tmp0,tmp0,tmp10
 movi_i64 tmp10,$0x1
 and_i64 tmp0,tmp0,tmp10
 ext32u_i64 tmp8,xcc
 movi_i64 tmp10,$0x14
 shr_i64 tmp8,tmp8,tmp10
 movi_i64 tmp10,$0x1
 and_i64 tmp8,tmp8,tmp10
 or_i64 tmp8,tmp8,tmp0
 movi_i64 tmp10,$0x1
 xor_i64 tmp8,tmp8,tmp10
 movi_i64 tmp10,$0x0
 brcond_i64 tmp8,tmp10,eq,$0x2
 mov_i64 tmp0,g1
 st_i64 tmp0,regwptr,$0x88
 set_label $0x2
 movi_i64 tmp8,$0x680c
 st_i64 tmp8,regwptr,$0x38
 ld_i64 loc3,regwptr,$0x88
 st_i64 loc3,regwptr,$0x20
 movi_i64 pc,$0x13f00
 movi_i64 npc,$0x13f04
 exit_tb $0x0
 end 

OUT: [size=797]
0x409551a0:  callq  0x526810
0x409551a5:  mov    0x40(%r14),%rbp
0x409551a9:  mov    0x0(%rbp),%rbx
0x409551ad:  add    $0xb,%rbx
0x409551b1:  mov    %rbx,%rsi
0x409551b4:  mov    %rbx,%rdi
0x409551b7:  shr    $0x8,%rsi
0x409551bb:  and    $0xffffffffffffe000,%rdi
0x409551c2:  and    $0x1fe0,%esi
0x409551c8:  lea    0x1238(%r14,%rsi,1),%rsi
0x409551d0:  cmp    (%rsi),%rdi
0x409551d3:  mov    %rbx,%rdi
0x409551d6:  jne    0x409551e1
0x409551d8:  add    0x18(%rsi),%rdi
0x409551dc:  movzbl (%rdi),%ebp
0x409551df:  jmp    0x409551eb
0x409551e1:  xor    %esi,%esi
0x409551e3:  callq  0x52c290
0x409551e8:  movzbl %al,%ebp
0x409551eb:  mov    0x40(%r14),%rbx
0x409551ef:  mov    0x88(%rbx),%r12
0x409551f6:  mov    0x90(%rbx),%r13
0x409551fd:  sub    %r13,%r12
0x40955200:  mov    %r12,0x88(%rbx)
0x40955207:  mov    (%rbx),%r12
0x4095520a:  add    $0xc,%r12
0x4095520e:  mov    %rbp,0x8(%r14)
0x40955212:  mov    %r12,%rsi
0x40955215:  mov    %r12,%rdi
0x40955218:  shr    $0x8,%rsi
0x4095521c:  and    $0xffffffffffffe000,%rdi
0x40955223:  and    $0x1fe0,%esi
0x40955229:  lea    0x1238(%r14,%rsi,1),%rsi
0x40955231:  cmp    (%rsi),%rdi
0x40955234:  mov    %r12,%rdi
0x40955237:  jne    0x40955242
0x40955239:  add    0x18(%rsi),%rdi
0x4095523d:  movzbl (%rdi),%ebp
0x40955240:  jmp    0x4095524c
0x40955242:  xor    %esi,%esi
0x40955244:  callq  0x52c290
0x40955249:  movzbl %al,%ebp
0x4095524c:  mov    $0x1dc00,%ebx
0x40955251:  mov    0x40(%r14),%r12
0x40955255:  mov    %rbx,(%r12)
0x40955259:  mov    0x8(%r14),%rbx
0x4095525d:  shl    $0x8,%rbx
0x40955261:  mov    0xb0(%r12),%r13
0x40955269:  add    $0x7ef,%r13
0x40955270:  mov    %rbx,0x8(%r14)
0x40955274:  mov    %rbp,0x10(%r14)
0x40955278:  mov    %r13,%rsi
0x4095527b:  mov    %r13,%rdi
0x4095527e:  shr    $0x8,%rsi
0x40955282:  and    $0xffffffffffffe007,%rdi
0x40955289:  and    $0x1fe0,%esi
0x4095528f:  lea    0x1238(%r14,%rsi,1),%rsi
0x40955297:  cmp    (%rsi),%rdi
0x4095529a:  mov    %r13,%rdi
0x4095529d:  jne    0x409552ab
0x4095529f:  add    0x18(%rsi),%rdi
0x409552a3:  mov    (%rdi),%rbp
0x409552a6:  bswap  %rbp
0x409552a9:  jmp    0x409552b5
0x409552ab:  xor    %esi,%esi
0x409552ad:  callq  0x52a900
0x409552b2:  mov    %rax,%rbp
0x409552b5:  mov    %rbp,%rbx
0x409552b8:  mov    0x40(%r14),%r12
0x409552bc:  mov    (%r12),%r15
0x409552c0:  or     $0x258,%r15
0x409552c7:  mov    %r15,(%r12)
0x409552cb:  mov    0x8(%r14),%r15
0x409552cf:  mov    0x10(%r14),%r10
0x409552d3:  or     %r15,%r10
0x409552d6:  shl    $0x10,%r10
0x409552da:  mov    0x88(%r12),%r15
0x409552e2:  mov    %rbx,%r11
0x409552e5:  sub    %r11,%r15
0x409552e8:  mov    %r10,%r11
0x409552eb:  mov    %r11d,%r11d
0x409552ee:  shr    $0x8,%r11
0x409552f2:  mov    %rbx,%r9
0x409552f5:  mov    %r9,0x18(%r12)
0x409552fa:  mov    %r10d,%r10d
0x409552fd:  shr    $0x18,%r10
0x40955301:  mov    %r10,%r9
0x40955304:  or     %r9,%r11
0x40955307:  mov    %r11,%r9
0x4095530a:  shl    $0x30,%r9
0x4095530e:  shr    $0x30,%r9
0x40955312:  mov    %r9,%r8
0x40955315:  mov    0x90(%r12),%rcx
0x4095531d:  mov    %r8,%rdx
0x40955320:  mov    %r9,0x18248(%r14)
0x40955327:  mov    %rbp,0x18250(%r14)
0x4095532e:  mov    %r13,0x18258(%r14)
0x40955335:  mov    %rcx,0x60(%r14)
0x40955339:  mov    %rdx,0x68(%r14)
0x4095533d:  mov    %r15,0x70(%r14)
0x40955341:  mov    $0x7,%ebp
0x40955346:  mov    %ebp,0x78(%r14)
0x4095534a:  mov    %r10,0x8(%r14)
0x4095534e:  mov    %r8,0x10(%r14)
0x40955352:  mov    %rbx,0x18(%r14)
0x40955356:  mov    %r11,0x20(%r14)
0x4095535a:  test   %rdx,%rdx
0x4095535d:  jne    0x4095536d
0x40955363:  mov    $0x28,%edi
0x40955368:  callq  0x523f50
0x4095536d:  mov    0x60(%r14),%rax
0x40955371:  xor    %edx,%edx
0x40955373:  mov    0x68(%r14),%rbp
0x40955377:  div    %rbp
0x4095537a:  mov    0x10(%r14),%rbx
0x4095537e:  imul   %rbx,%rax
0x40955382:  mov    %rax,%r12
0x40955385:  mov    %rax,0x18248(%r14)
0x4095538c:  mov    %r12,0x8(%r14)
0x40955390:  callq  0x526810
0x40955395:  mov    0x19230(%r14),%ebp
0x4095539c:  mov    %ebp,%ebx
0x4095539e:  shr    $0x16,%rbx
0x409553a2:  and    $0x1,%ebx
0x409553a5:  mov    %ebp,%r12d
0x409553a8:  shr    $0x14,%r12
0x409553ac:  and    $0x1,%r12d
0x409553b0:  or     %rbx,%r12
0x409553b3:  xor    $0x1,%r12
0x409553b7:  test   %r12,%r12
0x409553ba:  je     0x409553cf
0x409553c0:  mov    0x18(%r14),%rbp
0x409553c4:  mov    0x40(%r14),%rbx
0x409553c8:  mov    %rbp,0x88(%rbx)
0x409553cf:  mov    0x20(%r14),%rbp
0x409553d3:  shl    $0x10,%rbp
0x409553d7:  mov    0x40(%r14),%rbx
0x409553db:  mov    0x90(%rbx),%r12
0x409553e2:  mov    0x8(%r14),%r13
0x409553e6:  sub    %r13,%r12
0x409553e9:  mov    %rbp,%r13
0x409553ec:  mov    %r13d,%r13d
0x409553ef:  shr    $0x10,%r13
0x409553f3:  mov    %r13,0x8(%rbx)
0x409553f7:  mov    0x10(%r14),%r13
0x409553fb:  mov    %r13,%r15
0x409553fe:  sub    %r12,%r15
0x40955401:  mov    0x8(%rbx),%r12
0x40955405:  mov    %r12d,%r12d
0x40955408:  movslq %r12d,%r12
0x4095540b:  mov    %r12,0x8(%rbx)
0x4095540f:  mov    0x88(%rbx),%r12
0x40955416:  mov    %r15,%r10
0x40955419:  mov    %r12,%r11
0x4095541c:  sub    %r10,%r11
0x4095541f:  mov    %r11,%r9
0x40955422:  mov    %r9,0x18248(%r14)
0x40955429:  mov    %r10,0x68(%r14)
0x4095542d:  mov    %r11,0x70(%r14)
0x40955431:  mov    %r12,0x60(%r14)
0x40955435:  mov    $0x7,%ebx
0x4095543a:  mov    %ebx,0x78(%r14)
0x4095543e:  mov    %r15,0x8(%r14)
0x40955442:  mov    %rbp,0x20(%r14)
0x40955446:  callq  0x526810
0x4095544b:  mov    0x19230(%r14),%ebp
0x40955452:  mov    %ebp,%ebx
0x40955454:  shr    $0x16,%rbx
0x40955458:  and    $0x1,%ebx
0x4095545b:  mov    %ebp,%r12d
0x4095545e:  shr    $0x14,%r12
0x40955462:  and    $0x1,%r12d
0x40955466:  or     %rbx,%r12
0x40955469:  xor    $0x1,%r12
0x4095546d:  test   %r12,%r12
0x40955470:  je     0x40955485
0x40955476:  mov    0x8(%r14),%rbp
0x4095547a:  mov    0x40(%r14),%rbx
0x4095547e:  mov    %rbp,0x88(%rbx)
0x40955485:  mov    $0x680c,%ebp
0x4095548a:  mov    0x40(%r14),%rbx
0x4095548e:  mov    %rbp,0x38(%rbx)
0x40955492:  mov    0x88(%rbx),%rbp
0x40955499:  mov    %rbp,0x20(%rbx)
0x4095549d:  mov    %rbp,0x18248(%r14)
0x409554a4:  mov    $0x13f00,%ebp
0x409554a9:  mov    %rbp,0x48(%r14)
0x409554ad:  mov    $0x13f04,%ebp
0x409554b2:  mov    %rbp,0x50(%r14)
0x409554b6:  xor    %eax,%eax
0x409554b8:  jmpq   0x108e4ee

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

[Artyom Tarasenko]

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.

>When singlestepping via GDB, the
> result is correct.

You mean singlestepping gives other result than just setting a
breakpoint at target address?
And just to clarify, with 'singlestepping' do you mean manual stepping
through the code, or the '-singlestep' qemu option?

> I think this could be a bug in Qemu so I am attaching the relevant
> portion of qemu.log with some comments and pointers in it.
>
> I would appreciate if someone who understands the sparc64 code
> translation could have a look at this. More debugging data may be
> provided upon request.
>
> Thanks,
> Jakub
>
> _______________________________________________
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
>
>



-- 
Regards,
Artyom Tarasenko

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

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

[Jakub Jermar]

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

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 <jakub@jermar.eu> wrote:
> 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.

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
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
>



-- 
Regards,
Artyom Tarasenko

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

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

[Jakub Jermar]

[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]

On 1.7.2011 12:41, Artyom Tarasenko wrote:
> 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).

Yes I have a small reproducible testcase, see the attachments.

When _not_ singlestepping via GDB's `stepi`, the testcase will fail and
crash Qemu like this:

qemu: fatal: Trap 0x0101 while trap level (5) >= MAXTL (5), Error state
<register dumped here>

On the other hand, when I attach GDB to Qemu and step through all
instructions using `stepi`, the testcase will succeed and crash Qemu
like this:

qemu: fatal: Trap 0x0100 while trap level (5) >= MAXTL (5), Error state
<registers dumped here>

Mind the difference in the trap type - 0x100 for success, 0x101 for failure.

This is how I run the test:

Without GDB:
$ qemu-system-sparc64 -bios ./testcase

With GDB:
$ qemu-system-sparc64 -bios ./testcase -s -S

>From another terminal:
$ /usr/local/cross/sparc64/bin/sparc64-linux-gnu-gdb
(gdb) set architecture sparc:v9
(gdb) target remote localhost:1234
(gdb) stepi
...

Hope this helps to fix the problem.

Jakub

[-- Attachment #2: Makefile --]
[-- Type: text/plain, Size: 216 bytes --]

.PHONY=all
all:
	rm *.o testcase
	/usr/local/cross/sparc64/bin/sparc64-linux-gnu-as -g testcase.S -o testcase.o
	/usr/local/cross/sparc64/bin/sparc64-linux-gnu-ld -Ttext 0x00 testcase.o -o testcase --oformat binary


[-- Attachment #3: testcase --]
[-- Type: application/octet-stream, Size: 116 bytes --]

[-- Attachment #4: testcase.S --]
[-- Type: text/plain, Size: 444 bytes --]

.global _start 

.register %g2, #scratch
.register %g3, #scratch

.text

.space 0x20

_start:
	set 110393, %i1
	set 0, %i2
	set 131072, %g1
	set 0x40, %g3

	cmp  %i1, %g3
	srl  %g1, 8, %g4
	srl  %g1, 0x18, %g1
	or  %g4, %g1, %g4
	sllx  %g4, 0x30, %g2
	srlx  %g2, 0x30, %g2
	udivx  %i2, %g2, %g1
	mulx  %g1, %g2, %g1
	movgu  %xcc, %g3, %i1
	sub  %i2, %g1, %g1
	sub  %g2, %g1, %g1
	cmp  %i1, %g1
	bgu  %xcc, 0f
	nop

succ:
	ta 0

fail:
0:
	ta 1

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

[Jakub Jermar]

On 1.7.2011 14:57, Jakub Jermar wrote:
> On 1.7.2011 12:41, Artyom Tarasenko wrote:
>> 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).
> 
> Yes I have a small reproducible testcase, see the attachments.

Actually, the testcase can be further reduced into:

.global _start

.text

.space 0x20

_start:
	set 110393, %i1
	set 0x40, %i2

	cmp  %i1, %i2
	udivx  %g0, 1, %g0
	movgu  %xcc, %i2, %i1
	cmp  %i1, 512
	bgu  %xcc, 0f
	nop

succ:
	ta 0

fail:
0:
	ta 1

The presence of the `udivx` instruction seems to be essential. Even
though it has no effect on the computation, removing it will make the
testcase non-reproducible.

Jakub

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

[Laurent Desnogues]

On Fri, Jul 1, 2011 at 2:57 PM, Jakub Jermar <jakub@jermar.eu> wrote:
[...]
> When _not_ singlestepping via GDB's `stepi`, the testcase will fail and
> crash Qemu like this:
>
> qemu: fatal: Trap 0x0101 while trap level (5) >= MAXTL (5), Error state
> <register dumped here>
>
> On the other hand, when I attach GDB to Qemu and step through all
> instructions using `stepi`, the testcase will succeed and crash Qemu
> like this:
>
> qemu: fatal: Trap 0x0100 while trap level (5) >= MAXTL (5), Error state
> <registers dumped here>
>
> Mind the difference in the trap type - 0x100 for success, 0x101 for failure.
>
> This is how I run the test:
>
> Without GDB:
> $ qemu-system-sparc64 -bios ./testcase
>
> With GDB:
> $ qemu-system-sparc64 -bios ./testcase -s -S
>
> From another terminal:
> $ /usr/local/cross/sparc64/bin/sparc64-linux-gnu-gdb
> (gdb) set architecture sparc:v9
> (gdb) target remote localhost:1234
> (gdb) stepi
> ...
>
> Hope this helps to fix the problem.

You don't have to use gdb to reproduce the issue, just add -singlestep
when running qemu.

I find it odd that udivx is using cpu_cc_src and cpu_cc_src2.  Using
dedicated local temps seems to fix the issue.

HTH,

Laurent

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

[Jakub Jermar]

On 1.7.2011 16:15, Laurent Desnogues wrote:
> You don't have to use gdb to reproduce the issue, just add -singlestep
> when running qemu.

This is strange, -singlestep does not work for me here as the testcase
still ends with trap 0x101. The only way how the testcase can succeed
for me is via GDB's stepi.

Jakub

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

[Laurent Desnogues]

On Fri, Jul 1, 2011 at 4:11 PM, Jakub Jermar <jakub@jermar.eu> wrote:
[...]
> Actually, the testcase can be further reduced into:
>
> .global _start
>
> .text
>
> .space 0x20
>
> _start:
>        set 110393, %i1
>        set 0x40, %i2
>
>        cmp  %i1, %i2
>        udivx  %g0, 1, %g0
>        movgu  %xcc, %i2, %i1
>        cmp  %i1, 512
>        bgu  %xcc, 0f
>        nop
>
> succ:
>        ta 0
>
> fail:
> 0:
>        ta 1
>
> The presence of the `udivx` instruction seems to be essential. Even
> though it has no effect on the computation, removing it will make the
> testcase non-reproducible.

Could you try to replace udivx with sdivx?  It looks wrong too.


Laurent

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

[Jakub Jermar]

On 1.7.2011 16:24, Laurent Desnogues wrote:
> On Fri, Jul 1, 2011 at 4:11 PM, Jakub Jermar <jakub@jermar.eu> wrote:
> [...]
>> Actually, the testcase can be further reduced into:
>>
>> .global _start
>>
>> .text
>>
>> .space 0x20
>>
>> _start:
>>        set 110393, %i1
>>        set 0x40, %i2
>>
>>        cmp  %i1, %i2
>>        udivx  %g0, 1, %g0
>>        movgu  %xcc, %i2, %i1
>>        cmp  %i1, 512
>>        bgu  %xcc, 0f
>>        nop
>>
>> succ:
>>        ta 0
>>
>> fail:
>> 0:
>>        ta 1
>>
>> The presence of the `udivx` instruction seems to be essential. Even
>> though it has no effect on the computation, removing it will make the
>> testcase non-reproducible.
> 
> Could you try to replace udivx with sdivx?  It looks wrong too.

Yeah, `sdivx` behaves the same wrt. the testcase.

Jakub

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

[Artyom Tarasenko]

On Fri, Jul 1, 2011 at 4:15 PM, Laurent Desnogues
<laurent.desnogues@gmail.com> wrote:
> On Fri, Jul 1, 2011 at 2:57 PM, Jakub Jermar <jakub@jermar.eu> wrote:
> [...]
>> When _not_ singlestepping via GDB's `stepi`, the testcase will fail and
>> crash Qemu like this:
>>
>> qemu: fatal: Trap 0x0101 while trap level (5) >= MAXTL (5), Error state
>> <register dumped here>
>>
>> On the other hand, when I attach GDB to Qemu and step through all
>> instructions using `stepi`, the testcase will succeed and crash Qemu
>> like this:
>>
>> qemu: fatal: Trap 0x0100 while trap level (5) >= MAXTL (5), Error state
>> <registers dumped here>
>>
>> Mind the difference in the trap type - 0x100 for success, 0x101 for failure.
>>
>> This is how I run the test:
>>
>> Without GDB:
>> $ qemu-system-sparc64 -bios ./testcase
>>
>> With GDB:
>> $ qemu-system-sparc64 -bios ./testcase -s -S
>>
>> From another terminal:
>> $ /usr/local/cross/sparc64/bin/sparc64-linux-gnu-gdb
>> (gdb) set architecture sparc:v9
>> (gdb) target remote localhost:1234
>> (gdb) stepi
>> ...
>>
>> Hope this helps to fix the problem.

It definitely does, thanks a lot Jakub!

> You don't have to use gdb to reproduce the issue, just add -singlestep
> when running qemu.
>
> I find it odd that udivx is using cpu_cc_src and cpu_cc_src2.  Using
> dedicated local temps seems to fix the issue.

Do we need to copy cpu_src* to further temps at all? IMHO

-                        tcg_gen_mov_tl(cpu_cc_src, cpu_src1);
-                        tcg_gen_mov_tl(cpu_cc_src2, cpu_src2);
-                        gen_trap_ifdivzero_tl(cpu_cc_src2);
-                        tcg_gen_divu_i64(cpu_dst, cpu_cc_src, cpu_cc_src2);
+                        gen_trap_ifdivzero_tl(cpu_src2);
+                        tcg_gen_divu_i64(cpu_dst, cpu_src1, cpu_src2);

should do it. Or cpu_src is what you mean by dedicated?

-- 
Regards,
Artyom Tarasenko

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

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

[Artyom Tarasenko]

On Fri, Jul 1, 2011 at 4:28 PM, Jakub Jermar <jakub@jermar.eu> wrote:
> On 1.7.2011 16:24, Laurent Desnogues wrote:
>> On Fri, Jul 1, 2011 at 4:11 PM, Jakub Jermar <jakub@jermar.eu> wrote:
>> [...]
>>> Actually, the testcase can be further reduced into:
>>>
>>> .global _start
>>>
>>> .text
>>>
>>> .space 0x20
>>>
>>> _start:
>>>        set 110393, %i1
>>>        set 0x40, %i2
>>>
>>>        cmp  %i1, %i2
>>>        udivx  %g0, 1, %g0
>>>        movgu  %xcc, %i2, %i1
>>>        cmp  %i1, 512
>>>        bgu  %xcc, 0f
>>>        nop
>>>
>>> succ:
>>>        ta 0
>>>
>>> fail:
>>> 0:
>>>        ta 1
>>>
>>> The presence of the `udivx` instruction seems to be essential. Even
>>> though it has no effect on the computation, removing it will make the
>>> testcase non-reproducible.
>>
>> Could you try to replace udivx with sdivx?  It looks wrong too.
>
> Yeah, `sdivx` behaves the same wrt. the testcase.

Don't need to. Will send a qemu patch tonight. Great job! Once more,
thanks a lot!


-- 
Regards,
Artyom Tarasenko

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

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

[Laurent Desnogues]

On Fri, Jul 1, 2011 at 5:03 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
[...]
>> I find it odd that udivx is using cpu_cc_src and cpu_cc_src2.  Using
>> dedicated local temps seems to fix the issue.
>
> Do we need to copy cpu_src* to further temps at all? IMHO
>
> -                        tcg_gen_mov_tl(cpu_cc_src, cpu_src1);
> -                        tcg_gen_mov_tl(cpu_cc_src2, cpu_src2);
> -                        gen_trap_ifdivzero_tl(cpu_cc_src2);
> -                        tcg_gen_divu_i64(cpu_dst, cpu_cc_src, cpu_cc_src2);
> +                        gen_trap_ifdivzero_tl(cpu_src2);
> +                        tcg_gen_divu_i64(cpu_dst, cpu_src1, cpu_src2);
>
> should do it. Or cpu_src is what you mean by dedicated?

You have to use two local temps here to store cpu_src1
and cpu_src2 because gen_trap_ifdivzero_tl uses
tcg_gen_brcondi_tl (cf tcg/README comment about
local usage and jumps).  Note you'll have to do something
similar in gen_op_sdivx.


Laurent

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

[Artyom Tarasenko]

On Fri, Jul 1, 2011 at 5:20 PM, Laurent Desnogues
<laurent.desnogues@gmail.com> wrote:
> On Fri, Jul 1, 2011 at 5:03 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
> [...]
>>> I find it odd that udivx is using cpu_cc_src and cpu_cc_src2.  Using
>>> dedicated local temps seems to fix the issue.
>>
>> Do we need to copy cpu_src* to further temps at all? IMHO
>>
>> -                        tcg_gen_mov_tl(cpu_cc_src, cpu_src1);
>> -                        tcg_gen_mov_tl(cpu_cc_src2, cpu_src2);
>> -                        gen_trap_ifdivzero_tl(cpu_cc_src2);
>> -                        tcg_gen_divu_i64(cpu_dst, cpu_cc_src, cpu_cc_src2);
>> +                        gen_trap_ifdivzero_tl(cpu_src2);
>> +                        tcg_gen_divu_i64(cpu_dst, cpu_src1, cpu_src2);
>>
>> should do it. Or cpu_src is what you mean by dedicated?
>
> You have to use two local temps here to store cpu_src1
> and cpu_src2 because gen_trap_ifdivzero_tl uses
> tcg_gen_brcondi_tl (cf tcg/README comment about
> local usage and jumps).

The same story as the recent crash with wrpr %pstate, I see. I should
have done my homework.
Thanks for the hint!

Artyom

-- 
Regards,
Artyom Tarasenko

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

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

[Artyom Tarasenko]

On Fri, Jul 1, 2011 at 5:53 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
> On Fri, Jul 1, 2011 at 5:20 PM, Laurent Desnogues
> <laurent.desnogues@gmail.com> wrote:
>> On Fri, Jul 1, 2011 at 5:03 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
>> [...]
>>>> I find it odd that udivx is using cpu_cc_src and cpu_cc_src2.  Using
>>>> dedicated local temps seems to fix the issue.
>>>
>>> Do we need to copy cpu_src* to further temps at all? IMHO
>>>
>>> -                        tcg_gen_mov_tl(cpu_cc_src, cpu_src1);
>>> -                        tcg_gen_mov_tl(cpu_cc_src2, cpu_src2);
>>> -                        gen_trap_ifdivzero_tl(cpu_cc_src2);
>>> -                        tcg_gen_divu_i64(cpu_dst, cpu_cc_src, cpu_cc_src2);
>>> +                        gen_trap_ifdivzero_tl(cpu_src2);
>>> +                        tcg_gen_divu_i64(cpu_dst, cpu_src1, cpu_src2);
>>>
>>> should do it. Or cpu_src is what you mean by dedicated?
>>
>> You have to use two local temps here to store cpu_src1
>> and cpu_src2 because gen_trap_ifdivzero_tl uses
>> tcg_gen_brcondi_tl (cf tcg/README comment about
>> local usage and jumps).

Thought on a second thought, it's only critical if the jump is taken,
right? And here if the jump is taken, we don't need  cpu_src1 &
cpu_src2.

> The same story as the recent crash with wrpr %pstate, I see. I should
> have done my homework.
> Thanks for the hint!




-- 
Regards,
Artyom Tarasenko

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