Bah. Should have gone to the list as well.
r~
-- Forwarded message --
From: Richard Henderson
Date: Fri, Jul 7, 2017 at 6:38 AM
Subject: [PATCH v2.5] fixup! linux-user/sh4: Notice gUSA regions during
signal delivery
To: glaub...@physik.fu-berlin.de
Cc: laur...@vivier.eu
This fixes the signal delivery problem reported. I'll fold this into
the patch properly for v3, but this will allow reasonable testing to
proceed in the meantime.
r~
---
linux-user/signal.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 8c0b851..d68bd26 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -3476,13 +3476,18 @@ static abi_ulong get_sigframe(struct
target_sigaction *ka,
translate such sequences differently in a parallel context. */
static void unwind_gusa(CPUSH4State *regs)
{
-/* If the stack pointer is sufficiently negative ... */
-if ((regs->gregs[15] & 0xc000u) == 0xc000u
-/* ... and we haven't completed the sequence ... */
-&& regs->pc < regs->gregs[0]) {
+/* If the stack pointer is sufficiently negative, and we haven't
+ completed the sequence, then reset to the entry to the region. */
+/* ??? The SH4 kernel checks for and address above 0xC000.
+ However, the page mappings in qemu linux-user aren't as restricted
+ and we wind up with the normal stack mapped above 0xF000.
+ That said, there is no reason why the kernel should be allowing
+ a gUSA region that spans 1GB. Use a tighter check here, for what
+ can actually be enabled by the immediate move. */
+if (regs->gregs[15] >= -128u && regs->pc < regs->gregs[0]) {
/* Reset the PC to before the gUSA region, as computed from
- R0 = region end, SP = -(region size), plus one more insn
- that actually sets SP to the region size. */
+ R0 = region end, SP = -(region size), plus one more for the
+ insn that actually initializes SP to the region size. */
regs->pc = regs->gregs[0] + regs->gregs[15] - 2;
/* Reset the SP to the saved version in R1. */
--
2.9.4