qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1095531] Re: sparc32plus (and others?) has x86 cod


From: Samuel Seay
Subject: Re: [Qemu-devel] [Bug 1095531] Re: sparc32plus (and others?) has x86 code generation errors on 64bit hosts
Date: Tue, 11 Jul 2017 20:31:35 -0000

I no longer have a setup to test this so I can only say to close it.

On Jul 11, 2017 4:15 PM, "Thomas Huth" <address@hidden>
wrote:

> Can you still reproduce this problem wit the latest release of QEMU
> (currently version 2.9.0), or could we close this bug nowadays?
>
> ** Changed in: qemu
>        Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1095531
>
> Title:
>   sparc32plus (and others?) has x86 code generation errors on 64bit
>   hosts
>
> Status in QEMU:
>   Incomplete
>
> Bug description:
>   On 64bit hosts, the load and store functions compile improperly. The
>   issue is the call to gen_address_mask() under the ld and st functions
>   in target-sparc/translate.c. Below are some snips from the log file.
>   Doing a gdb debug, this results in constant access violation errors
>   which I do not see when debugging qemu in powerpc mode.
>
>   --------------
>   IN:
>   0x0000000040804aa8:  st  %i0, [ %fp + 0x44 ]
>
>   OP:
>    ---- 0x40804aa8
>    ld_i64 tmp1,regwptr,$0xb0
>    mov_i64 tmp0,tmp1
>    movi_i64 tmp2,$0x44
>    add_i64 tmp0,tmp0,tmp2
>    ld_i64 tmp2,regwptr,$0x80
>    ext32u_i64 tmp0,tmp0
>    qemu_st32 tmp2,tmp0,$0x0
>
>   OUT: [size=345]
>   0x6032d7f0:  mov    0x40(%r14),%rbp
>   0x6032d7f4:  mov    0xb0(%rbp),%rbx
>   0x6032d7fb:  add    $0x44,%rbx
>   0x6032d7ff:  mov    0x80(%rbp),%rbp
>   0x6032d806:  mov    %ebx,%ebx                 <- bug
>   0x6032d808:  mov    %ebp,%edi
>   0x6032d80a:  bswap  %edi
>   0x6032d80c:  mov    %edi,(%rbx)
>
>   --------------
>   IN:
>   0x0000000040804aec:  add  %l7, %o7, %l7
>   0x0000000040804af0:  ld  [ %l7 ], %g2
>
>   OP:
>    ---- 0x40804aec
>    ld_i64 tmp1,regwptr,$0x78
>    ld_i64 tmp2,regwptr,$0x38
>    add_i64 tmp0,tmp1,tmp2
>    st_i64 tmp0,regwptr,$0x78
>
>    ---- 0x40804af0
>    ld_i64 tmp1,regwptr,$0x78
>    mov_i64 tmp0,tmp1
>    ext32u_i64 tmp0,tmp0
>    qemu_ld32u g2,tmp0,$0x0
>
>   OUT: [size=395]
>   0x6032da80:  mov    0x40(%r14),%rbp
>   0x6032da84:  mov    0x78(%rbp),%rbx
>   0x6032da88:  mov    0x38(%rbp),%r12
>   0x6032da8c:  add    %r12,%rbx
>   0x6032da8f:  mov    %rbx,0x78(%rbp)
>   0x6032da93:  mov    0x78(%rbp),%rbx
>   0x6032da97:  mov    %ebx,%ebx                <- bug
>   0x6032da99:  mov    (%rbx),%ebx
>
>   In 64bit mode, doing a 32bit operation will result in the top 32bit's
>   being zero'd. I attempted to simply disable the call to
>   gen_address_mask() but that did not fix the issue and actually caused
>   the sparc32plus I was testing to become unusable.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1095531/+subscriptions
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1095531

Title:
  sparc32plus (and others?) has x86 code generation errors on 64bit
  hosts

Status in QEMU:
  Incomplete

Bug description:
  On 64bit hosts, the load and store functions compile improperly. The
  issue is the call to gen_address_mask() under the ld and st functions
  in target-sparc/translate.c. Below are some snips from the log file.
  Doing a gdb debug, this results in constant access violation errors
  which I do not see when debugging qemu in powerpc mode.

  --------------
  IN: 
  0x0000000040804aa8:  st  %i0, [ %fp + 0x44 ]

  OP:
   ---- 0x40804aa8
   ld_i64 tmp1,regwptr,$0xb0
   mov_i64 tmp0,tmp1
   movi_i64 tmp2,$0x44
   add_i64 tmp0,tmp0,tmp2
   ld_i64 tmp2,regwptr,$0x80
   ext32u_i64 tmp0,tmp0
   qemu_st32 tmp2,tmp0,$0x0

  OUT: [size=345]
  0x6032d7f0:  mov    0x40(%r14),%rbp
  0x6032d7f4:  mov    0xb0(%rbp),%rbx
  0x6032d7fb:  add    $0x44,%rbx
  0x6032d7ff:  mov    0x80(%rbp),%rbp
  0x6032d806:  mov    %ebx,%ebx                 <- bug
  0x6032d808:  mov    %ebp,%edi
  0x6032d80a:  bswap  %edi
  0x6032d80c:  mov    %edi,(%rbx)

  --------------
  IN: 
  0x0000000040804aec:  add  %l7, %o7, %l7
  0x0000000040804af0:  ld  [ %l7 ], %g2

  OP:
   ---- 0x40804aec
   ld_i64 tmp1,regwptr,$0x78
   ld_i64 tmp2,regwptr,$0x38
   add_i64 tmp0,tmp1,tmp2
   st_i64 tmp0,regwptr,$0x78

   ---- 0x40804af0
   ld_i64 tmp1,regwptr,$0x78
   mov_i64 tmp0,tmp1
   ext32u_i64 tmp0,tmp0
   qemu_ld32u g2,tmp0,$0x0

  OUT: [size=395]
  0x6032da80:  mov    0x40(%r14),%rbp
  0x6032da84:  mov    0x78(%rbp),%rbx
  0x6032da88:  mov    0x38(%rbp),%r12
  0x6032da8c:  add    %r12,%rbx
  0x6032da8f:  mov    %rbx,0x78(%rbp)
  0x6032da93:  mov    0x78(%rbp),%rbx
  0x6032da97:  mov    %ebx,%ebx                <- bug
  0x6032da99:  mov    (%rbx),%ebx

  In 64bit mode, doing a 32bit operation will result in the top 32bit's
  being zero'd. I attempted to simply disable the call to
  gen_address_mask() but that did not fix the issue and actually caused
  the sparc32plus I was testing to become unusable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1095531/+subscriptions



reply via email to

[Prev in Thread] Current Thread [Next in Thread]