On 14 October 2016 at 07:44, Alex Bennée <alex.ben...@linaro.org> wrote: > > Peter Maydell <peter.mayd...@linaro.org> writes: > >> In the ARM v6 architecture, 'sub pc, pc, 1' is not an interworking >> branch, so the computed new value is written to r15 as a normal >> value. The architecture says that in this case, bits [1:0] of >> the value written must be ignored if we are in ARM mode (or >> bit [0] ignored if in Thumb mode); this is a change from the >> ARMv4/v5 specification that behaviour is UNPREDICTABLE. >> Use the correct mask on the PC value when doing a non-interworking >> store to PC. >> >> A popular library used on RaspberryPi uses this instruction >> as part of a trick to determine whether it is running on >> ARMv6 or ARMv7, and we were mishandling the sequence. >> >> Fixes bug: https://bugs.launchpad.net/bugs/1625295 >> >> Reported-by: <stu.a...@gmail.com> >> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> >> Message-id: 1474380941-4730-1-git-send-email-peter.mayd...@linaro.org > > I'm not sure how but this seems to have regressed my ARMv7 test images > (currently Linux 4.7.7). With this change I see the guest spinning in > the vectors table. If I comment out the change it boots. > > I'll dig some more but as this affects store_reg are there any cases > when writing to the PC with offset bits would be correct?
Look for the patch I sent earlier that fixes a regression in returning from exceptions to thumb addresses that are only 2 aligned. That will probably fix it. thanks -- PMM
