target/hppa: be,n nullifying first insn at branch target?

[Sven Schnelle]

Hi Richard,

one of the last issue i'm seeing with 64bit HP-UX 11.11 is a crash
of ld64 while building (linking) the kernel. The program is killed
due to a unaligned access. I've wrote a logfile, and it looks like
be,n is nullifying the first instruction at the branch target:

IN: 
0x9d4a4000016d4fc:  cmpiclr,<> c,r31,r0
0x9d4a4000016d500:  addi,tr 13,r0,ret1
0x9d4a4000016d504:  ldi 0,ret1
0x9d4a4000016d508:  ldi 0,ret0
0x9d4a4000016d50c:  ldsid (rp),r31
0x9d4a4000016d510:  mtsp r31,sr0
0x9d4a4000016d514:  be,n 0(sr0,rp)

Trace 0: 0x7efd7f9d75c0 [9d4a40000000004/09d4a4000016d4fc/00040306/ff000000] 
IA_F 09d4a4000016d4ff IA_B 09d4a4000016d503 IIR 000000004afc3ff9
PSW  000000ff0004ff1f CB   1111111111111111 ---------C---RQPDI
GR00 0000000000000000 GR01 0000000009d4a400 GR02 0000000000107573 GR03 
00000000003c79b8
GR04 0000000000419f50 GR05 0000000000410a30 GR06 000000007a0005c8 GR07 
0000000000419f50
GR08 00000000004122f8 GR09 000000000000000b GR10 00000000001db1b8 GR11 
00000000001c81f8
GR12 00000000001c81f8 GR13 00000000001c81f8 GR14 0000000000000000 GR15 
00000000001dbf18
GR16 0000000000000000 GR17 0000000000000001 GR18 00000000001d5278 GR19 
00000000001c5000
GR20 0000000000416a40 GR21 000000000000006a GR22 000000000016d4e8 GR23 
000000000000004a
GR24 000000000000029c GR25 0000000000000000 GR26 0000000000419f50 GR27 
00000000001e65f8
GR28 0000000000000001 GR29 00000000001db1b8 GR30 000000007a029510 GR31 
000000000000000c
SR00 09d4a400 SR01 00000000 SR02 00000000 SR03 00000000
SR04 09d4a400 SR05 09d4a400 SR06 01eea400 SR07 01eea400

----------------
IN: 
0x9d4a40000107570:  ldw 0(r4),r19
0x9d4a40000107574:  ldw 58(r19),r22
0x9d4a40000107578:  ldo 0(ret1),r7
0x9d4a4000010757c:  ldo 0(r4),r26
0x9d4a40000107580:  b,l 0x9d4a400001074d8,r31
0x9d4a40000107584:  ldo 0(r31),rp

Trace 0: 0x7efd7f9d77c0 [9d4a40000000004/09d4a40000107570/00240306/ff000000] 
IA_F 09d4a40000107573 IA_B 09d4a40000107577 IIR 000000004afc3ff9
PSW  000000000024001f CB   0000000000000000 ------N--C---RQPDI
GR00 0000000000000000 GR01 0000000009d4a400 GR02 0000000000107573 GR03 
00000000003c79b8
GR04 0000000000419f50 GR05 0000000000410a30 GR06 000000007a0005c8 GR07 
0000000000419f50
GR08 00000000004122f8 GR09 000000000000000b GR10 00000000001db1b8 GR11 
00000000001c81f8
GR12 00000000001c81f8 GR13 00000000001c81f8 GR14 0000000000000000 GR15 
00000000001dbf18
GR16 0000000000000000 GR17 0000000000000001 GR18 00000000001d5278 GR19 
00000000001c5000
GR20 0000000000416a40 GR21 000000000000006a GR22 000000000016d4e8 GR23 
000000000000004a
GR24 000000000000029c GR25 0000000000000000 GR26 0000000000419f50 GR27 
00000000001e65f8
GR28 0000000000000000 GR29 0000000000000013 GR30 000000007a029510 GR31 
0000000009d4a400
SR00 09d4a400 SR01 00000000 SR02 00000000 SR03 00000000
SR04 09d4a400 SR05 09d4a400 SR06 01eea400 SR07 01eea400

Trace 0: 0x7efd7f9adb80 [9d4a40000000004/09d4a400001074d8/00040306/ff000000] 
IA_F 09d4a400001074db IA_B 09d4a400001074df IIR 000000004afc3ff9
PSW  000000000004001f CB   0000000000000000 ---------C---RQPDI
GR00 0000000000000000 GR01 0000000009d4a400 GR02 000000000010758b GR03 
00000000003c79b8
GR04 0000000000419f50 GR05 0000000000410a30 GR06 000000007a0005c8 GR07 
0000000000000013
GR08 00000000004122f8 GR09 000000000000000b GR10 00000000001db1b8 GR11 
00000000001c81f8
GR12 00000000001c81f8 GR13 00000000001c81f8 GR14 0000000000000000 GR15 
00000000001dbf18
GR16 0000000000000000 GR17 0000000000000001 GR18 00000000001d5278 GR19 
00000000001c5000
GR20 0000000000416a40 GR21 000000000000006a GR22 0000000024000000 GR23 
000000000000004a
GR24 000000000000029c GR25 0000000000000000 GR26 0000000000419f50 GR27 
00000000001e65f8
GR28 0000000000000000 GR29 0000000000000013 GR30 000000007a029510 GR31 
000000000010758b
SR00 09d4a400 SR01 00000000 SR02 00000000 SR03 00000000
SR04 09d4a400 SR05 09d4a400 SR06 01eea400 SR07 01eea400

The problem is the 0x1c5000 value in r19, which is the value of an old
instruction. At 0x9d4a4000016d514 is a be,n and at 09d4a40000107570 the
N bit is set. First i thought it might be just a display issue with the
log, but the following change to confirm the issue makes the kernel
linking succeed:


diff --git a/target/hppa/translate.c b/target/hppa/translate.c
index 7546a5f5a2..56c68a7cbe 100644
--- a/target/hppa/translate.c
+++ b/target/hppa/translate.c
@@ -3847,7 +3849,7 @@ static bool trans_be(DisasContext *ctx, arg_be *a)
         copy_iaoq_entry(ctx, cpu_gr[31], ctx->iaoq_n, ctx->iaoq_n_var);
         tcg_gen_mov_i64(cpu_sr[0], cpu_iasq_b);
     }
-    if (a->n && use_nullify_skip(ctx)) {
+    if (0 && a->n && use_nullify_skip(ctx)) {
         copy_iaoq_entry(ctx, cpu_iaoq_f, -1, tmp);
         tcg_gen_addi_i64(tmp, tmp, 4);
         copy_iaoq_entry(ctx, cpu_iaoq_b, -1, tmp);


So i think the problem is caused by this optimization. Does this ring a
bell? Debugging this is rather hard, alone the logfile above is 6GB in
size...

Thanks,
Sven