On 14 October 2016 at 07:44, Alex Bennée <[email protected]> wrote: > > Peter Maydell <[email protected]> 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: <[email protected]> >> Signed-off-by: Peter Maydell <[email protected]> >> Message-id: [email protected] > > 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
