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.

-- PMM

Reply via email to