diff options
Diffstat (limited to 'results/classifier/118/user-level/1843133')
| -rw-r--r-- | results/classifier/118/user-level/1843133 | 194 |
1 files changed, 194 insertions, 0 deletions
diff --git a/results/classifier/118/user-level/1843133 b/results/classifier/118/user-level/1843133 new file mode 100644 index 00000000..e6d1bde8 --- /dev/null +++ b/results/classifier/118/user-level/1843133 @@ -0,0 +1,194 @@ +user-level: 0.872 +permissions: 0.854 +debug: 0.851 +device: 0.820 +mistranslation: 0.798 +semantic: 0.788 +peripherals: 0.783 +arm: 0.780 +register: 0.778 +architecture: 0.776 +files: 0.775 +vnc: 0.770 +risc-v: 0.769 +performance: 0.768 +ppc: 0.752 +hypervisor: 0.740 +VMM: 0.740 +network: 0.740 +PID: 0.730 +graphic: 0.729 +kernel: 0.717 +assembly: 0.716 +socket: 0.715 +TCG: 0.713 +virtual: 0.707 +boot: 0.699 +KVM: 0.630 +x86: 0.599 +i386: 0.569 +-------------------- +x86: 0.980 +assembly: 0.947 +debug: 0.887 +hypervisor: 0.201 +register: 0.180 +virtual: 0.163 +files: 0.057 +TCG: 0.051 +semantic: 0.042 +performance: 0.026 +PID: 0.026 +risc-v: 0.022 +kernel: 0.018 +device: 0.017 +boot: 0.015 +VMM: 0.015 +socket: 0.013 +i386: 0.010 +vnc: 0.007 +user-level: 0.007 +peripherals: 0.006 +permissions: 0.005 +ppc: 0.005 +architecture: 0.004 +network: 0.003 +graphic: 0.002 +mistranslation: 0.002 +KVM: 0.001 +arm: 0.000 + +Possibly incorrect branch in qemu-system-hppa + +I plan to release a new GNU Lightning soon. +I no longer have access to any physical HPPA, but code that +was tested some years ago did work on HPPA/HP-UX, and now it +appears qemu-system-hppa incorrectly branches in code generated +by GNU Lightning. Currently only 32 bit hppa jit generation +supported. + +In the lightning check/test tool, the code would be: + +.code + prolog + movi %r0 0x7fffffff + movi %r1 1 + boaddr L0 %r0 %r1 + calli @abort +L0: + ret + epilog + +The code/debug information looks like this: + movi r4 0x7fffffff + 0xf8ef5018 ldil L%7ffff800,r4 + 0xf8ef501c ldo 7ff(r4),r4 + movi r5 0x1 + 0xf8ef5020 ldi 1,r5 + boaddr L1 r4 r5 + 0xf8ef5024 addb,sv,n r5,r4,0xf8ef5044 :a.tst:291 + 0xf8ef5028 nop + calli 0xf8eeb68a + [...] + L1: + +Apparently it is not understanding 0x7fffffff + 1 is a signed overflow. + +Tested in Fedora with qemu-system-hppa-3.1.1-2.fc30.x86_64 and using +the debian-10 image. + +To make it a bit easier to test (partially transformed the +not so optimized code generated by lightning to gcc -S output): +# cat a.s + .LEVEL 1.1 + .text + .align 4 +.globl main + .type main, @function +main: + .PROC + .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3 + .ENTRY + copy %r3,%r1 + copy %r30,%r3 + stwm %r1,64(%r30) + zdepi -1,31,31,%r23 + ldi 1,%r24 + addb,sv,n %r24,%r23,.L0 + nop + ldi 1,%r28 + b,n .L1 + nop +.L0: + ldi 0,%r28 +.L1: + ldo 64(%r3),%r30 + ldwm -64(%r30),%r3 + bv,n %r0(%r2) + .EXIT + .PROCEND + .size main, .-main + +# gcc a.s +# ./a.out; echo $? +1 + +It should have returned 0. + +As a side note, the branch is correct if testing 0xffffffe + 2 +or other combinations to cause a signed overflow. The only +special pattern that fails is '0x7ffffff + 1'. + + +This test case works for me. + +$ ./hppa-linux-user/qemu-hppa ~/a.out +$ echo $? +0 + +From -d in_asm,cpu logs: + +IN: main +0x000112d0: addb,*<,n r24,r23,0x112e4 + +IA_F 000112d3 IA_B 000112d7 +PSW 0000bf00 CB 11111111 ------------------ +GR00 00000000 GR01 00000000 GR02 0001162b GR03 ff7fe9c0 +GR04 00011b94 GR05 00011c6c GR06 00000000 GR07 00000000 +GR08 00000000 GR09 00000000 GR10 00000000 GR11 00000000 +GR12 00000000 GR13 00000000 GR14 00000000 GR15 00000000 +GR16 00000000 GR17 00000000 GR18 00000000 GR19 ff7fe888 +GR20 00000000 GR21 00000000 GR22 000112bc GR23 7fffffff +GR24 00000001 GR25 ff7fe674 GR26 00000001 GR27 0009a0e0 +GR28 0009f080 GR29 00000001 GR30 ff7fea00 GR31 0001162b + +About to execute the addb; r23 and r24 as expected. + +---------------- +IN: main +0x000112e4: ldi 0,ret0 + +IA_F 000112e7 IA_B 000112eb +PSW 0000bf00 CB 11111111 ------------------ +GR00 00000000 GR01 00000000 GR02 0001162b GR03 ff7fe9c0 +GR04 00011b94 GR05 00011c6c GR06 00000000 GR07 00000000 +GR08 00000000 GR09 00000000 GR10 00000000 GR11 00000000 +GR12 00000000 GR13 00000000 GR14 00000000 GR15 00000000 +GR16 00000000 GR17 00000000 GR18 00000000 GR19 ff7fe888 +GR20 00000000 GR21 00000000 GR22 000112bc GR23 80000000 +GR24 00000001 GR25 ff7fe674 GR26 00000001 GR27 0009a0e0 +GR28 0009f080 GR29 00000001 GR30 ff7fea00 GR31 0001162b + +The branch has been taken, correctly. +We can see the expected result in r23. + +I've also tested this in system mode, though getting logs +from that is significantly more difficult. + +I am testing git master, not v3.1.1. Can you please try +the development version? + +I built qemu 4.1.0, and the problem no longer happens. +It is good enough for me. + + |