Bah.  Should have gone to the list as well.

r~
---------- Forwarded message ----------
From: Richard Henderson <rth@twiddle.net>
Date: Fri, Jul 7, 2017 at 6:38 AM
Subject: [PATCH v2.5] fixup! linux-user/sh4: Notice gUSA regions during
signal delivery
To: glaubitz@physik.fu-berlin.de
Cc: laurent@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] & 0xc0000000u) == 0xc0000000u
-        /* ... 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 0xC0000000.
+       However, the page mappings in qemu linux-user aren't as restricted
+       and we wind up with the normal stack mapped above 0xF0000000.
+       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

On 07/07/2017 07:57 AM, Richard Henderson wrote:
> +    /* ??? The SH4 kernel checks for and address above 0xC0000000.
> +       However, the page mappings in qemu linux-user aren't as restricted
> +       and we wind up with the normal stack mapped above 0xF0000000.
> +       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.  */

Additionally, I can (and should) fix the address space problem for SH4 in 
linux-user/main.c, where we have already done so for MIPS and Nios2.

See the initialization of reserved_va.


r~

On 2017-07-07 09:00, Richard Henderson wrote:
> On 07/07/2017 07:57 AM, Richard Henderson wrote:
> > +    /* ??? The SH4 kernel checks for and address above 0xC0000000.
> > +       However, the page mappings in qemu linux-user aren't as restricted
> > +       and we wind up with the normal stack mapped above 0xF0000000.
> > +       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.  */
> 
> Additionally, I can (and should) fix the address space problem for SH4 in
> linux-user/main.c, where we have already done so for MIPS and Nios2.
> 
> See the initialization of reserved_va.

I guess it's what you have done in the "linux-user fixes for va
mapping", which renders this version 2.5 obsolete. Therefore I guess the
version 2 is the one to be used instead.

Unfortunately my knowledge of linux-user is rather limited to review
this new series.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net