On 4/1/24 10:39, Sven Schnelle wrote:
Richard Henderson <richard.hender...@linaro.org> writes:
On 4/1/24 04:52, Sven Schnelle wrote:
For unknown reasons, Java 1.5 on 64-bit HP-UX 11.11 does signed
computation of the new IAOQ value in the signal handler. In the
current code these bits are not masked when returning to narrow
mode, causing java to crash.
Signed-off-by: Sven Schnelle <sv...@stackframe.org>
---
target/hppa/sys_helper.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/target/hppa/sys_helper.c b/target/hppa/sys_helper.c
index 208e51c086..3bbc2da71b 100644
--- a/target/hppa/sys_helper.c
+++ b/target/hppa/sys_helper.c
@@ -83,6 +83,10 @@ void HELPER(rfi)(CPUHPPAState *env)
env->iaoq_f = env->cr[CR_IIAOQ];
env->iaoq_b = env->cr_back[1];
+ if (!(env->cr[CR_IPSW] & PSW_W)) {
+ env->iaoq_f &= 0xffffffff;
+ env->iaoq_b &= 0xffffffff;
+ }
This shouldn't be needed, because we are already masking these bits
later, in cpu_get_tb_cpu_state. But I do have some cleanups in this
area, and perhaps one of them matters.
Ouch. Appologies, i removed that masking to make 64 bit work, but forgot
about that. Sorry. I tried your branch, but i'm not able to boot 64 bit HP-UX
(it wasn't working before without additional changes, so your branch
doesn't break it). However, i would like to get your oppinion before
debugging. The code is:
IN:
0xef4680000002c18: 20 20 08 01 ldil L%-40000000,r1
0xef4680000002c1c: e4 20 e0 08 be,l 4(sr7,r1),sr0,r31
0xef4680000002c20: 34 16 00 72 ldi 39,r22
IA_F 0ef46800:0000000000002c23 (0ef4680000002c23)
IA_B 01e27c00:ffffffffc0000007 (01e27c00c0000007)
PSW 000000000004000f CB 0000000000000000 ---------C----QPDI
GR00 0000000000000000 GR01 ffffffffc0000000 GR02 0000000000002ac3 GR03
000000007a000000
GR04 0000000000000002 GR05 000000007a000034 GR06 000000007a000040 GR07
000000007a000050
GR08 000000007a0000e0 GR09 8000000040001000 GR10 0000000000000003 GR11
0000000000000006
GR12 00000000001ecee8 GR13 00000000ffffffff GR14 0000000000000801 GR15
0000000000000006
GR16 80000000400020c0 GR17 000000000001e720 GR18 0000000000000008 GR19
0000000000000000
GR20 000000000ef46800 GR21 000000007a000060 GR22 0000000000000000 GR23
000000007a000050
GR24 0000000000000000 GR25 0000000000000000 GR26 000000007a0020f0 GR27
0000000040008410
GR28 0000000000000002 GR29 0000000000000000 GR30 000000007a002160 GR31
0000000000002c27
RC 000000007fffffff CR1 0000000000000000 CR2 0000000000000000 CR3
0000000000000000
CR4 0000000000000000 CR5 0000000000000000 CR6 0000000000000002 CR7
fffffffffffb0000
PID1 000000000000256f PID2 0000000000007306 CCR 00000000000000c0 SAR
0000000000000004
PID3 0000000000000000 PID4 0000000000000000 IVA 000000000002a000 EIEM
ffffffffffffffff
ITMR 00000005d637f804 ISQF 000000000ef46800 IOQF 0000000000002aab IIR
000000006bc23fd9
ISR 0000000004d0d000 IOR 400000007a0020cc IPSW 000000000004000f EIRR
0000000000000000
TR0 0000000000abfe68 TR1 000000000465d1d6 TR2 0000000000000002 TR3
0000000000000000
TR4 0000000000000000 TR5 00000001757973bb TR6 00000000000021eb TR7
000000007a0020e0
ISQB 000000000ef46800 IOQB 0000000000002aaf
SR00 0ef46800 SR01 00000000 SR02 00000000 SR03 00000000
SR04 0ef46800 SR05 04d0d000 SR06 01e27c00 SR07 01e27c00
INT 3529: instruction tlb miss fault @ 0000000001e27c00:ffffffffc0000007 for
0000000001e27c00:40000000c0000004
INT 3530: instruction tlb miss fault @ 0000000000000000:ffffffffc0000007 for
0000000000000000:40000000c0000004
INT 3531: external interrupt @ 0000000000000000:ffffffffc0000007 for
0000000000000000:40000000c0000004
INT 3532: instruction tlb miss fault @ 0000000000000000:ffffffffc0000007 for
0000000000000000:40000000c0000004
INT 3533: external interrupt @ 0000000000000000:ffffffffc0000007 for
0000000000000000:40000000c0000004
So the PSW indicates narrow mode, but IAOQ seems to contain all the
ffff... bits.
I believe that the IAOQ *should* contain all of the bits. The bits should only be
discarded when we form the GVA -- exactly like "ldb 0(r2)", where r2 contains all of the
offset bits. In particular, I believe that "b,l .+8,r2" should copy all of those bits to
r2 from IAOQ_Back+4 and the fact that mainline crops those bits is a bug.
Also interesting is that the second TLB miss (INT 3530)
misses the Space ID.
That is a bit curious, yes.
Any thoughts? Otherwise i need to investigate and make a wrong patch
again :-)
The only patch i have on top which touches target/hppa is the space id
hashing mask patch:
Ok. I do have an hppa 11.11 iso -- for clarity, what is your command-line?
r~