qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH] linux-user/arm: Reset CPSR_E when entering a signal handler


From: Peter Maydell
Subject: Re: [PATCH] linux-user/arm: Reset CPSR_E when entering a signal handler
Date: Fri, 15 May 2020 22:25:22 +0100

On Fri, 15 May 2020 at 21:41, Amanieu d'Antras <address@hidden> wrote:
> On Fri, May 15, 2020 at 7:34 PM Peter Maydell <address@hidden> wrote:
> > I was just looking at the signal code's handling of CPSR for a different
> > reason, and I noticed that at the moment we don't allow CPSR.E to be
> > updated from the signal frame when the signal handler returns
> > (because CPSR_USER doesn't contain CPSR_E and that's what we
> > use in restore_sigcontext() to define what bits from the frame we
> > allow updating). Don't you find that when the interrupted code
> > returns from the signal handler that it ends up running with the
> > wrong endianness (ie the endianness the handler used) ?
>
> I actually found this while trying to test the SETEND instruction
> under risu. The signal handler was crashing because it loaded a
> pointer with the wrong endianness, which was pretty obvious. However I
> missed the fact that code was now running with the wrong endianness
> after returning from the signal handler since I had both the master
> and the apprentice running under qemu-arm.
>
> > I'm going to fix this by putting CPSR_E in CPSR_USER, anyway.
>
> You also need to call arm_rebuild_hflags() after modifying CPSR_E
> otherwise the change doesn't take effect.

Hmm. I was expecting cpsr_write() to take care of that if we
updated a cpsr flag that was in the hflags, but it looks like
the rebuild_hflags() is in the HELPER() wrapper but not in
cpsr_write() itself. Richard, does anything go wrong if
cpsr_write() proper does the hflags rebuild ?

thanks
-- PMM



reply via email to

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