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

[Samuel Seay]

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.

[Samuel Seay (lightningth)]

I forgot to add, this is on the latest master branch as of this post. I am doing a static compile with debug enabled. My test is doing a chroot of a sparc system built from debootstrap.

[Thomas Huth (th-huth)]

Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays?

[Samuel Seay (lightningth)]

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" <email 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
>

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]