summaryrefslogtreecommitdiffstats
path: root/results/classifier/zero-shot/118/mistranslation-risc-v/1095531
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/zero-shot/118/mistranslation-risc-v/1095531')
-rw-r--r--results/classifier/zero-shot/118/mistranslation-risc-v/1095531215
1 files changed, 215 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/mistranslation-risc-v/1095531 b/results/classifier/zero-shot/118/mistranslation-risc-v/1095531
new file mode 100644
index 00000000..07e875bb
--- /dev/null
+++ b/results/classifier/zero-shot/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.]
+