c++ - 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:

When an instruction reads the PC, the value read depends on which instruction set it comes from:

• For an ARM instruction, the value read is the address of the instruction plus 8 bytes. Bits [1:0] of this value are always zero, because ARM instructions are always word-aligned.
• For a Thumb instruction, the value read is the address of the instruction plus 4 bytes. Bit [0] of this value is always zero, because Thumb instructions are always halfword-aligned.

This way of reading the PC is primarily used for quick, position-independent addressing of nearby instructions and data, including position-independent branching within a program.

相对于 pc 的寻址有两个原因。

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

---

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