diff options
Diffstat (limited to 'results/classifier/118/mistranslation-risc-v/1095531')
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/1095531 | 215 |
1 files changed, 215 insertions, 0 deletions
diff --git a/results/classifier/118/mistranslation-risc-v/1095531 b/results/classifier/118/mistranslation-risc-v/1095531 new file mode 100644 index 000000000..07e875bba --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/1095531 @@ -0,0 +1,215 @@ +risc-v: 0.850 +mistranslation: 0.833 +user-level: 0.830 +permissions: 0.723 +TCG: 0.719 +hypervisor: 0.692 +ppc: 0.689 +peripherals: 0.687 +VMM: 0.685 +semantic: 0.674 +graphic: 0.655 +debug: 0.645 +x86: 0.642 +device: 0.639 +performance: 0.638 +architecture: 0.630 +assembly: 0.607 +register: 0.592 +arm: 0.587 +KVM: 0.579 +PID: 0.556 +vnc: 0.552 +files: 0.542 +boot: 0.518 +socket: 0.508 +virtual: 0.499 +kernel: 0.443 +i386: 0.432 +network: 0.409 +-------------------- +x86: 0.992 +assembly: 0.963 +debug: 0.947 +files: 0.085 +TCG: 0.062 +register: 0.042 +kernel: 0.033 +ppc: 0.021 +i386: 0.016 +virtual: 0.012 +PID: 0.008 +semantic: 0.006 +VMM: 0.006 +architecture: 0.005 +device: 0.004 +hypervisor: 0.003 +performance: 0.003 +KVM: 0.003 +boot: 0.002 +user-level: 0.002 +mistranslation: 0.002 +graphic: 0.001 +risc-v: 0.001 +peripherals: 0.001 +socket: 0.001 +network: 0.001 +permissions: 0.001 +vnc: 0.001 +arm: 0.000 + +sparc32plus (and others?) has x86 code generation errors on 64bit hosts + +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. + +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. + +Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? + +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 +> + + +[Expired for QEMU because there has been no activity for 60 days.] + |