1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
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.
|