On 2017-07-15 16:33, Richard Henderson wrote: > On 07/15/2017 12:59 PM, Aurelien Jarno wrote: > > On 2017-07-06 16:20, Richard Henderson wrote: > > > If a signal is delivered during the execution of a delay slot, > > > or a gUSA region, clear those bits from the environment so that > > > the signal handler does not start in that same state. > > > > How are signals delivered in linux-user? At least in system mode we > > forbid interrupts in the delay slot (see commit 5c6f3eb7db), as the > > manual clearly declare them as indivisible. Maybe the same should be > > done for linux-user? > > Signals get queued, and delivered eventually. I don't believe that we do > anything to check that "signals can't be delivered yet" like we do in system > mode.
Ok. I think it might be a good idea to implement that. I am not always sure that running the signal handler between an instruction and the corresponding delay slot will lead to correct behaviour. > > > + regs->flags &= ~(DELAY_SLOT_MASK | GUSA_MASK); > > > } > > > static void setup_frame(int sig, struct target_sigaction *ka, > > > > Why not using TB_FLAG_ENVFLAGS_MASK introduced earlier in this patch > > series? > > I really want to clear these two sets. I didn't want to assume that > ENVFLAGS_MASK would never contain anything else. > Fair enough. Therefore: Reviewed-by: Aurelien Jarno <aurel...@aurel32.net> -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
