diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1095 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1095531 | 170 | ||||
| -rw-r--r-- | results/classifier/108/other/1095857 | 31 |
3 files changed, 217 insertions, 0 deletions
diff --git a/results/classifier/108/other/1095 b/results/classifier/108/other/1095 new file mode 100644 index 00000000..5cb2cbc5 --- /dev/null +++ b/results/classifier/108/other/1095 @@ -0,0 +1,16 @@ +other: 0.833 +network: 0.767 +device: 0.685 +semantic: 0.675 +boot: 0.378 +performance: 0.377 +graphic: 0.358 +vnc: 0.324 +socket: 0.323 +KVM: 0.293 +permissions: 0.239 +PID: 0.238 +files: 0.125 +debug: 0.120 + +[QUESTION] What IF.... diff --git a/results/classifier/108/other/1095531 b/results/classifier/108/other/1095531 new file mode 100644 index 00000000..8101766a --- /dev/null +++ b/results/classifier/108/other/1095531 @@ -0,0 +1,170 @@ +other: 0.724 +permissions: 0.723 +semantic: 0.674 +graphic: 0.655 +debug: 0.645 +device: 0.639 +performance: 0.638 +KVM: 0.579 +PID: 0.556 +vnc: 0.552 +files: 0.542 +boot: 0.518 +socket: 0.508 +network: 0.409 + +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.] + diff --git a/results/classifier/108/other/1095857 b/results/classifier/108/other/1095857 new file mode 100644 index 00000000..07c66ba8 --- /dev/null +++ b/results/classifier/108/other/1095857 @@ -0,0 +1,31 @@ +graphic: 0.736 +device: 0.679 +performance: 0.570 +other: 0.555 +semantic: 0.442 +debug: 0.408 +network: 0.323 +socket: 0.242 +boot: 0.214 +vnc: 0.198 +permissions: 0.167 +PID: 0.156 +files: 0.154 +KVM: 0.114 + +incorrect handling of [r32] address (long mode) + +while executing in Long Mode (x86-64) instructions such as + +mov eax,[r15d] + +end up executing as + +mov eax,[r15] + +according to x86 programmer manuals the behavior of using the Address-Size override (in long mode) is supposed to ignore the high 32bits of the register. I use this fact in my operating system to reduce register usage (the high 32 bits of r15 holds other data). consequently a general protection exception occurs since the memory address isn't "canonical". this error doesn't always appear since the high 32 bits might not be zero in those conditions. + +You are correct about what the instruction is supposed to do. That said the behaviour you describe is not reproducible. Which version of QEMU are you using? Could you please send a testcase? + +[Expired for QEMU because there has been no activity for 60 days.] + |