On Fri, 15 May 2020 at 21:41, Amanieu d'Antras <aman...@gmail.com> wrote: > On Fri, May 15, 2020 at 7:34 PM Peter Maydell <peter.mayd...@linaro.org> > 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
