qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 08/27] linux-user/sh4: Notice gUSA regions du


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH v2 08/27] linux-user/sh4: Notice gUSA regions during signal delivery
Date: Fri, 7 Jul 2017 11:09:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

Le 07/07/2017 à 11:05, Laurent Vivier a écrit :
> Le 07/07/2017 à 04:20, Richard Henderson a écrit :
>> We translate gUSA regions atomically in a parallel context.
>> But in a serial context a gUSA region may be interrupted.
>> In that case, restart the region as the kernel would.
>>
>> Signed-off-by: Richard Henderson <address@hidden>
>> ---
>>  linux-user/signal.c | 23 +++++++++++++++++++++++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/linux-user/signal.c b/linux-user/signal.c
>> index 3d18d1b..a537778 100644
>> --- a/linux-user/signal.c
>> +++ b/linux-user/signal.c
>> @@ -3471,6 +3471,25 @@ static abi_ulong get_sigframe(struct target_sigaction 
>> *ka,
>>      return (sp - frame_size) & -8ul;
>>  }
>>  
>> +/* Notice when we're in the middle of a gUSA region and reset.
>> +   Note that this will only occur for !parallel_cpus, as we will
>> +   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]) {
>> +        /* 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.  */
>> +        regs->pc = regs->gregs[0] + regs->gregs[15] - 2;
>> +
>> +        /* Reset the SP to the saved version in R1.  */
>> +        regs->gregs[15] = regs->gregs[1];
>> +    }
>> +}
>> +
>>  static void setup_sigcontext(struct target_sigcontext *sc,
>>                               CPUSH4State *regs, unsigned long mask)
>>  {
>> @@ -3534,6 +3553,8 @@ static void setup_frame(int sig, struct 
>> target_sigaction *ka,
>>      abi_ulong frame_addr;
>>      int i;
>>  
>> +    unwind_gusa(regs);
>> +
>>      frame_addr = get_sigframe(ka, regs->gregs[15], sizeof(*frame));
> 
> I think unwind_gusa() should be moved after the get_sigfram() (in both
> cases), because r15  can be updated and the sigframe base lost.
> 

No, it's stupid, r15 is negative

Laurent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]