ldr 的奇怪行为 [pc, #value]

Question

我正在调试一些c++代码（ARM平台上的WinCE 6）， 我发现一些行为很奇怪：

    4277220C    mov         r3, #0x93, 30
    42772210    str         r3, [sp]
    42772214    ldr         r3, [pc, #0x69C]
    42772218    ldr         r2, [pc, #0x694]
    4277221C    mov         r1, #0
    42772220    ldr         r0, [pc, #0x688]

行 42772214 ldr r3, [pc, #0x69C] 用于从 .DATA 部分获取一些常量，至少我这么认为。

奇怪的是，根据代码，r2 应该填充来自地址 pc=0x42772214 + 0x69C = 0x427728B0 的内存，但根据从 0x427728B8（8 个字节+）加载的内存内容，其他 ldr 用法也会发生这种情况。

是调试器的错误还是我对 ldr/pc 的理解错误？ 我不明白的另一个问题 - 为什么对 .data 部分的访问与执行的代码相关？我觉得有点奇怪。

还有一个问题：我找不到第一个 mov 命令的语法（任何人都可以向我指出 Thumb (1C2) 的 optype 规范）

抱歉，我的描述很简单，但我只是熟悉程序集。

Answer 1

这是正确的。当使用pc读取时，ARM模式下有8字节偏移，Thumb模式下有4字节偏移。

来自ARM-ARM：

当一条指令读取PC时，读取的值取决于它来自哪个指令集：

• 对于 ARM 指令，读取的值是指令地址加上 8 个字节。该值的位 [1:0] 始终为零，因为 ARM 指令始终是字对齐的。
• 对于 Thumb 指令，读取的值是指令地址加上 4 个字节。该值的位 [0] 始终为零，因为 Thumb 指令始终半字对齐。

这种读取 PC 的方式主要用于对附近指令和数据进行快速、与位置无关的寻址，包括程序中与位置无关的分支。

使用 PC 相对寻址有两个原因。

1. 与位置无关的代码，适合您的情况。
2. 获取附近一些复杂的常量，这些常量无法用 1 条简单的指令来写，例如 mov r3, #0x12345678 是不可能用 1 条指令完成的，因此编译器可能会将这个常量放在函数的末尾并使用例如 ldr r3, [pc, #0x50] 来加载它。

---

我不知道 mov r3, #0x93, 30 是什么意思。可能是 mov r3, #0x93, rol 30 （给出 0xC0000024）？