After some discussion on the gbadev Discord server, it was found that pc has a "weird" behaviour when a bx instruction is executed to ARM state with a mis-aligned address (aka bit 1 set): while the CPU is able to "internally" align the address to fetch an instruction with correct alignment, on pc the bit1 keeps set, which can lead to miscalculations in any instruction that uses it as an operand (such as pc-relative loads and stores).
We can check the vaildity of this hypothesis with a very simple subroutine that gets the pc on such a state:
08001708 <getMisalignedPC>:
8001708: 46c0 nop @ (mov r8, r8)
800170a: 4778 bx pc @ this will branch to pc = 0800170e
800170c: e1a0000f mov r0, pc @ this will set r0 = mis-aligned pc: 08001716
8001710: e12fff1e bx lr
(the source file is like this)
.section .rom, "ax", %progbits
.align 2
.thumb_func
.global getMisalignedPC
.type getMisalignedPC STT_FUNC
getMisalignedPC:
nop ; to ensure mis-alignment (with the .align 2 up there)
bx pc ; this instruction will fetch a pc whose set bit is 1
.arm
mov r0, pc ; this pc should be misaligned as well
bx lr
(I tried to upload a GBA ROM here, but GitHub doesn't let me)
On the hardware (tested by @evanbowman), the returned PC is what is expected by the above hypothesis:
On mGBA, however, the returned PC is aligned to the lowest word (08001714), contradicting the result on hardware.
This aligns with what the ARM7TDMI Technical Reference says about bits 1 and 0 of pc on ARM state:
Whether or not instructions having pc as an operand will correctly use the "correct" (aligned) program counter value is not tested (though I doubt, since bl in Thumb sets bit 1 of lr).
After some discussion on the gbadev Discord server, it was found that
pchas a "weird" behaviour when abxinstruction is executed to ARM state with a mis-aligned address (aka bit 1 set): while the CPU is able to "internally" align the address to fetch an instruction with correct alignment, onpcthe bit1 keeps set, which can lead to miscalculations in any instruction that uses it as an operand (such as pc-relative loads and stores).We can check the vaildity of this hypothesis with a very simple subroutine that gets the
pcon such a state:(the source file is like this)
(I tried to upload a GBA ROM here, but GitHub doesn't let me)
On the hardware (tested by @evanbowman), the returned PC is what is expected by the above hypothesis:
On mGBA, however, the returned PC is aligned to the lowest word (
08001714), contradicting the result on hardware.This aligns with what the ARM7TDMI Technical Reference says about bits 1 and 0 of
pcon ARM state:Whether or not instructions having
pcas an operand will correctly use the "correct" (aligned) program counter value is not tested (though I doubt, sinceblin Thumb sets bit 1 oflr).