| Message ID | CAD-reDZ5RUnTm3JZG7rQ_dDSE41KJ_HoARQuiCLpT0wkdcowAQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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;
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(-) /* Reset the SP to the saved version in R1. */ -- 2.9.4