LDR奇怪的现象[PC,#VALUE] [英] Strange behaviour of ldr [pc, #value]

查看:164
本文介绍了LDR奇怪的现象[PC,#VALUE]的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我调试一些C ++ code(6 WinCE的ARM上的平台),
我发现一些奇怪的行为:

I was debugging some c++ code (WinCE 6 on ARM platform), and i find some behavior strange:

    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段某个常数,至少我是这么认为的。

Line 42772214 ldr r3, [pc, #0x69C] is used to get some constant from .DATA section, at least I think so.

什么奇怪的是,根据code R2应该充满地址从PC内存= 0x42772214 + 0x69C = 0x427728B0,但根据存储器中的内容它是从0x427728B8(8个字节+)加载,它发生其他LDR用途了。

What is strange that according to the code r2 should be filled with memory from address pc=0x42772214 + 0x69C = 0x427728B0, but according to the memory contents it's loaded from 0x427728B8 (8bytes+), it happens for other ldr usages too.

这是不是调试器或我的LDR / PC的理解错吗?
另外一个问题我不明白 - 为什么进入.data段是相对于执行code?我觉得有点怪怪的。

Is it fault of the debugger or my understanding of ldr/pc? Another issue I don't get - why access to the .data section is relative to the executed code? I find it little bit strange.

和多了一个问题:我找不到第一个MOV指令的语法(任何一个可以点我一个OPTYPE规范的拇指(1C2))

And one more issue: i cannot find syntax of the 1st mov command (any one could point me a optype specification for the Thumb (1C2))

对不起,凡人的描述,但我只是用组件熟悉。

Sorry for the laic description, but I'm just familiarizing with the assemblies.

推荐答案

这是正确的。当 PC 用于读取还是有8个字节,在Thumb模式偏移ARM模式和4字节偏移量。

This is correct. When pc is used for reading there is an 8-byte offset in ARM mode and 4-byte offset in Thumb mode.

从ARM-ARM:

当一个指令读取PC,阅读的价值取决于其指令集它来自:

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


      
  • 对于ARM指令,阅读值为指令的地址加8个字节。比特[1:0]。该值始终为零,因为ARM指令总是字对齐

  •   
  • 对于Thumb指令,阅读值为指令的地址加4个字节。这个值的位[0]始终为零,因为Thumb指令总是半字对齐。

  •   
  • 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.

的读出在PC这种方式主要用于快速,位置无关的附近的指令和数据,包括位置无关的节目内分枝寻址。

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相对地址。

There are 2 reasons for pc-relative addressing.


  1. 位置无关code,这是你的情况。

  2. 获取一些复杂的常数附近不能被写在1简单的指令,例如 MOV R3,#0x12345678的不可能在1个指令来完成的,所以编译器可以把这个常数函数的结束,例如使用 LDR R3,[PC,#为0x50] 加载它来代替。

  1. Position-independent code, which is in your case.
  2. Get some complicated constants nearby which cannot be written in 1 simple instruction, e.g. mov r3, #0x12345678 is impossible to complete in 1 instruction, so the compiler may put this constant in the end of the function and use e.g. ldr r3, [pc, #0x50] to load it instead.

我不知道是什么 MOV R3,#0x93,30 表示。也许这是 MOV R3,#0x93,ROL 3​​0 (这给 0xC0000024 )?


I don't know what mov r3, #0x93, 30 means. Probably it is mov r3, #0x93, rol 30 (which gives 0xC0000024)?

这篇关于LDR奇怪的现象[PC,#VALUE]的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆