Re: [Qemu-devel] x86 tcg problem

[Blue Swirl]

On 7/29/08, Vince Weaver <address@hidden> wrote:
> Hello
>
>  I've spent a day now trying to figure out why bzip2 compress/decompress
> doesn't work when using sparc32plus-linux-user on x86.
>
>  I've tracked the problem to the Zero flag being improperly set (attached is
> a small exe/src that reproduces the problem.. it reports "Greater"
>  on real hardware, "Less Than" on qemu current).
>
>  The issue seems to be a misordering of an x86 sub instruction.  I tried to
> track this down in the tcg code but I quickly got lost.
>
>  The code does this for a compare (on sparc the compare turns into a
> subtract with result as the [ignores] zero reg):
>
>   mov_i32 cc_src_0,g4_0                          ;
>   mov_i32 cc_src_1,g4_1                          ; load g4  (0xaae60)
>   mov_i32 cc_src2_0,g3_0                         ;
>   mov_i32 cc_src2_1,g3_1                         ; load g3  (0)
>   sub2_i32
> cc_dst_0,cc_dst_1,cc_src2_0,cc_src2_1,cc_src_0,cc_src_1
>                                                 ; result = 0xaafe0-0
>   movi_i32 psr,$0x0                              ; clear psr
>   mov_i32 tmp42,cc_dst_0                         ; get cc_dst_0
>   movi_i32 tmp43,$0x0                            ;
>   movi_i32 tmp44,$0x0                            ;
>   movi_i32 tmp45,$0x0                            ; zero extends
>   brcond2_i32 tmp42,tmp43,tmp44,tmp45,$0x1,$0x0  ; if not
> zero, skip
>   movi_i32 tmp19,$0x400000                       ; else set zero flag
>
>
>
>  which converts into x86:
>   0xb80da04d:  sub    %ecx,%eax          ; %ecx = g4-g3
>   0xb80da04f:  sbb    %ebx,%edx
>   0xb80da051:  mov    %eax,0x6c(%ebp)    ; saving g3, not the result (ecx)!
>   0xb80da054:  mov    %edx,0x70(%ebp)    ;
>   0xb80da057:  xor    %edx,%edx
>   0xb80da059:  xor    %ecx,%ecx          ; clearing our result for use as
> psr
>                                         ; result is lost!
>                                         ; the later test for zero is done
>                                         ; against g3 instead, which
>                                         ; sets the zero flag when it
>   ...                                    ; shouldn't
>   0xb80da06f:  test   %eax,%eax
>   0xb80da071:  jne    0xb80da091         ; skip if not zero
>   ..
>   0xb80da07f:  mov    0x8c(%ebp),%eax    ; load psr
>   0xb80da085:  or     $0x400000,%eax     ; set zero flag
>
>
>  So unless there's some weird AT&T/intel ordering thing that is confusing me
> (please let me know if I am missing something), TCG is getting confused
> about which argument of the subtract is the result.  I'm not sure how to fix
> this though...

Now I found the problem, (1 << 31) could be negative on 64 bit
variable. I'm testing a fix. It looks like this also solves some of
the Sparc64 boot problems, like Aurora 2.0 which complained about CRC
error.