在Thumb代码中使用BX调用Thumb函数，或在另一个函数中跳转到Thumb指令 [英] Using BX in Thumb code to call a Thumb function, or to jump to a Thumb instruction in another function
问题描述
我正在尝试学习在固件修改中有用的技能(我没有源代码) 这些问题涉及使用拇指代码中的BX跳转或调用其他现有的拇指代码.
I'm trying to learn skills useful in firmware modding (for which i don't have source code) These questions concern use of BX from thumb code to jump or call other existing thumb code.
- 如何使用BX从THUMB代码跳转到现有固件THUMB代码.
- 如何使用BX从我的THUMB代码中调用现有的THUMB函数(必须先设置LR).
我的理解是cpu查看lsb位(位0)，并且我必须确保将其设置为1，以便将cpu状态保持为拇指状态".
所以我想我必须加1来将lsb位置1.
My understanding is that cpu looks at lsb bit (bit 0) and i have to make sure this is set to 1 in order to keep cpu state to "thumb state".
So I guess i have to ADD 1, to set lsb bit to 1.
所以...说我想跳到0x24000(在一些现有的THUMB代码中间)
So ...say i want to just JUMP to 0x24000 ( in the middle of some existing THUMB code)
LDR R6, =0x24000
ADD R6, #1 @ (set lsb to 1)
BX R6
我认为这是正确的吗?
现在说我想使用BX调用现有的Thumb函数，并且希望它返回给我，因此我需要将LR设置为我希望它返回的位置.
Now say i want to CALL an existing thumb function, using BX, and i want it to return to me, so i need to set LR to where i want it to return.
可以说我要调用的函数位于0x24000 这是建议我使用:
Lets say the function i want to call is at 0x24000 It was suggested to me to use:
ldr r2, =0x24000
mov lr, pc
bx r2
这是我不明白的地方:
-
R2中的地址没有设置lsb位...所以
bx r2不会将模式切换到ARM模式吗?
the address in R2 doesn't have lsb bit set... so won't
bx r2switch mode to ARM mode??
LR .. 有人告诉我，PC的地址为(当前指令的开头+ 4). 在Thumb和Arm中，任何指令地址都必须对齐(16位或32位)，因此不会将LSB位设置为1.只有奇数将lsb位设置为1.
The LR.. The PC has the address of (begining of current instruction, + 4), i was told. In both Thumb and Arm, any instruction address has to be aligned (16 bit or 32 bit), so it won't have the LSB bit set to 1. Only odd numbers have lsb bit set to 1.
因此在上面的代码中，我将LR设置为(PC)，该地址也没有设置lsb位1.因此，当我调用的函数出现在结尾时，BX LR，... uhmmm ..该如何返回我的THUMB代码?我一定想念一些东西...
So in the code above, i'm setting LR to (PC), an address that DOESN'T have lsb bit 1 set either. So when the function i called comes to it's epilogue, and does BX LR, ... uhmmm.. how can that work to return to my THUMB code ? I must be missing something...
通常BL用于调用函数.手册说BL指令将LR设置为下一行代码...
那么这是否意味着(通常使用的)BL THUMB指令将LR自动设置为return addr + 1?
Normally BL is used to call functions. The manual says BL instruction sets the LR to the next line of code...
So does this mean that a (normally used) BL THUMB instruction, sets the LR to return addr + 1 automatically?
推荐答案
哇，谢谢你叫我.我知道我在 http://github.com/dwelch67/yagbat 中尝试了qemu代码，并想到了XPUT32它以您描述的方式调用PUT32，并且有效.但是它似乎没有用.我创建了许多实验，但很惊讶，这不是我所期望的.现在，我了解了为什么gnu链接器会执行它的操作.抱歉，这是一个很长的回复，但我认为它非常有价值.这是一个令人困惑的话题，我知道多年来我一直以为PC将模式拖了一些就错了，但事实并非如此.
Wow, thanks for calling me out on this one. I know I tried the qemu code in http://github.com/dwelch67/yagbat and thought XPUT32 which calls PUT32 in the way you describe, and it worked. But it DOES NOT appear to work. I created a number of experiments and am quite surprised, this is not what I was expecting. Now I see why the gnu linker does what it does. Sorry this is a long response but I think it very valuable. It is a confusing topic, I know I have had it wrong for years thinking the pc drags the mode bit around, but it doesn't.
在开始下面的实验之前，如果您要这样做:
Before I start with the experiments below, if you are going to do this:
LDR R6, =0x24000
ADD R6, #1 @ (set lsb to 1)
BX R6
因为您碰巧知道0x24000是拇指代码，所以只需这样做:
because you happen to know that 0x24000 is thumb code, just do this instead:
LDR R6, =0x24001
BX R6
是的，如果您碰巧知道硬编码的地址0x24000是您的bx拇指指令，并且寄存器中包含该地址加一个，那么这就是从手臂或拇指分支到拇指代码的方式.
And yes, that is how you branch to thumb code from arm or thumb if you happen to know that that hardcoded address 0x24000 is a thumb instruction you bx with a register containing the address plus one.
如果您不知道地址，但知道地址的名称:
If you don't know the address but know the name of the address:
ldr r6,=something
bx r6
有趣的是，某些东西可以是手臂或拇指的地址，而上面的代码也可以正常工作.如果链接器正确知道哪种类型的标签是手臂或拇指，它会起作用，如果该标签弄乱了，它将无法正常工作，如您在此处看到的那样:
The nice thing about that is that something can be an arm or thumb address and the above code just works. Well it works if the linker properly knows what type of label that is arm or thumb, if that gets messed up it won't work right as you can see here:
.thumb
ping:
ldr r0,=pong
bx r0
.code 32
pong:
ldr r0,=ping
bx r0
d6008148 <ping>:
d6008148: 4803 ldr r0, [pc, #12] ; (d6008158 <pong+0xc>)
d600814a: 4700 bx r0
d600814c <pong>:
d600814c: e59f0008 ldr r0, [pc, #8] ; d600815c <pong+0x10>
d6008150: e12fff10 bx r0
d6008158: d600814c strle r8, [r0], -ip, asr #2
d600815c: d6008148 strle r8, [r0], -r8, asr #2
那是行不通的.pong想从0xD600815C中提取一个大拇指地址，但得到了一个手臂地址.
That didn't work pong wanted to pull a thumb address from 0xD600815C but got an arm address.
所有这些都是gnu汇编程序的东西，对于其他工具，您可能不得不做其他事情.对于气体，您需要将.thumb_func放在要声明为拇指标签的标签之前(术语func隐含函数会引起误解，不必担心.thumb_func意味着它只是一个汇编程序/链接器游戏)./p>
This is all gnu assembler stuff btw, for other tools you may have to do something else. For gas you need to put .thumb_func before a label that you want declared as a thumb label (the term func implying function is misleading, don't worry about what .thumb_func means it just is an assembler/linker game).
.thumb
.thumb_func
ping:
ldr r0,=pong
bx r0
.code 32
pong:
ldr r0,=ping
bx r0
现在我们得到了想要的东西:
and now we get what we wanted:
d6008148 <ping>:
d6008148: 4803 ldr r0, [pc, #12] ; (d6008158 <pong+0xc>)
d600814a: 4700 bx r0
d600814c <pong>:
d600814c: e59f0008 ldr r0, [pc, #8] ; d600815c <pong+0x10>
d6008150: e12fff10 bx r0
d6008158: d600814c strle r8, [r0], -ip, asr #2
d600815c: d6008149 strle r8, [r0], -r9, asr #2
0xD600815C设置了lsbit，因此您无需执行任何工作.例如，当您调用C函数时，编译器会处理所有这些问题.对于汇编程序，尽管您必须使用.thumb_func(或其他一些指令，如果有的话)来使自己知道这是一个拇指标签并为您设置lsbit.
0xD600815C has that lsbit set so that you don't have to do any work. The compiler takes care of all of this when you are doing calls to C functions for example. For assembler though you have to use that .thumb_func (or some other directive if there is one) to get gas to know this is a thumb label and set the lsbit for you.
因此，下面的实验是在mpcore上完成的，该mpcore是ARM11，但我还在ARM7TDMI和qemu上尝试了testthumb函数1-4，结果相同.
So the experiment below was done on an mpcore which is an ARM11 but I also tried testthumb functions 1 through 4 on an ARM7TDMI and qemu with the same results.
.globl testarm
testarm:
mov r0,pc
bx lr
armbounce:
mov r0,lr
bx lr
.thumb
.thumb_func
.globl testthumb1
testthumb1:
mov r0,pc
bx lr
nop
nop
nop
bounce:
bx lr
.thumb_func
.globl testthumb2
testthumb2:
mov r2,lr
mov r0,pc
bl bounce
bx r2
nop
nop
nop
.thumb_func
.globl testthumb3
testthumb3:
mov r2,lr
mov lr,pc
mov r0,lr
bx r2
nop
nop
nop
.thumb_func
.globl testthumb4
testthumb4:
push {lr}
ldr r2,=armbounce
mov r1,pc ;@ -4
add r1,#5 ;@ -2
mov lr,r1 ;@ +0
bx r2 ;@ +2
pop {r2} ;@ +4
bx r2
.thumb_func
.globl testthumb5
testthumb5:
push {lr}
ldr r2,=armbounce
mov lr,pc
bx r2
pop {r2}
bx r2
.thumb_func
.globl testthumb6
testthumb6:
push {lr}
bl testthumb6a
.thumb_func
testthumb6a:
mov r0,lr
pop {r2}
bx r2
.thumb_func
.globl testthumb7
testthumb7:
push {lr}
bl armbounce_thumb
pop {r2}
bx r2
.thumb_func
.globl testthumb8
testthumb8:
push {lr}
bl armbounce_thumb_two
pop {r2}
bx r2
.align 4
armbounce_thumb:
ldr r1,[pc]
bx r1
.word armbounce
nop
.align 4
armbounce_thumb_two:
bx pc
nop
.code 32
b armbounce
哪个会成为:
d60080b4 <testarm>:
d60080b4: e1a0000f mov r0, pc
d60080b8: e12fff1e bx lr
d60080bc <armbounce>:
d60080bc: e1a0000e mov r0, lr
d60080c0: e12fff1e bx lr
d60080c4 <testthumb1>:
d60080c4: 4678 mov r0, pc
d60080c6: 4770 bx lr
d60080c8: 46c0 nop ; (mov r8, r8)
d60080ca: 46c0 nop ; (mov r8, r8)
d60080cc: 46c0 nop ; (mov r8, r8)
d60080ce <bounce>:
d60080ce: 4770 bx lr
d60080d0 <testthumb2>:
d60080d0: 4672 mov r2, lr
d60080d2: 4678 mov r0, pc
d60080d4: f7ff fffb bl d60080ce <bounce>
d60080d8: 4710 bx r2
d60080da: 46c0 nop ; (mov r8, r8)
d60080dc: 46c0 nop ; (mov r8, r8)
d60080de: 46c0 nop ; (mov r8, r8)
d60080e0 <testthumb3>:
d60080e0: 4672 mov r2, lr
d60080e2: 46fe mov lr, pc
d60080e4: 4670 mov r0, lr
d60080e6: 4710 bx r2
d60080e8: 46c0 nop ; (mov r8, r8)
d60080ea: 46c0 nop ; (mov r8, r8)
d60080ec: 46c0 nop ; (mov r8, r8)
d60080ee <testthumb4>:
d60080ee: b500 push {lr}
d60080f0: 4a15 ldr r2, [pc, #84] ; (d6008148 <armbounce_thumb_two+0x8>)
d60080f2: 4679 mov r1, pc
d60080f4: 3105 adds r1, #5
d60080f6: 468e mov lr, r1
d60080f8: 4710 bx r2
d60080fa: bc04 pop {r2}
d60080fc: 4710 bx r2
d60080fe <testthumb5>:
d60080fe: b500 push {lr}
d6008100: 4a11 ldr r2, [pc, #68] ; (d6008148 <armbounce_thumb_two+0x8>)
d6008102: 46fe mov lr, pc
d6008104: 4710 bx r2
d6008106: bc04 pop {r2}
d6008108: 4710 bx r2
d600810a <testthumb6>:
d600810a: b500 push {lr}
d600810c: f000 f800 bl d6008110 <testthumb6a>
d6008110 <testthumb6a>:
d6008110: 4670 mov r0, lr
d6008112: bc04 pop {r2}
d6008114: 4710 bx r2
d6008116 <testthumb7>:
d6008116: b500 push {lr}
d6008118: f000 f80a bl d6008130 <armbounce_thumb>
d600811c: bc04 pop {r2}
d600811e: 4710 bx r2
d6008120 <testthumb8>:
d6008120: b500 push {lr}
d6008122: f000 f80d bl d6008140 <armbounce_thumb_two>
d6008126: bc04 pop {r2}
d6008128: 4710 bx r2
d600812a: 46c0 nop ; (mov r8, r8)
d600812c: 46c0 nop ; (mov r8, r8)
d600812e: 46c0 nop ; (mov r8, r8)
d6008130 <armbounce_thumb>:
d6008130: 4900 ldr r1, [pc, #0] ; (d6008134 <armbounce_thumb+0x4>)
d6008132: 4708 bx r1
d6008134: d60080bc ; <UNDEFINED> instruction: 0xd60080bc
d6008138: 46c0 nop ; (mov r8, r8)
d600813a: 46c0 nop ; (mov r8, r8)
d600813c: 46c0 nop ; (mov r8, r8)
d600813e: 46c0 nop ; (mov r8, r8)
d6008140 <armbounce_thumb_two>:
d6008140: 4778 bx pc
d6008142: 46c0 nop ; (mov r8, r8)
d6008144: eaffffdc b d60080bc <armbounce>
d6008148: d60080bc ; <UNDEFINED> instruction: 0xd60080bc
d600814c: e1a00000 nop ; (mov r0, r0)
以及调用和打印所有这些函数的结果:
And the results of calling and printing all of these functions:
D60080BC testarm
D60080C8 testthumb1
D60080D6 testthumb2
D60080E6 testthumb3
D60080FB testthumb4
testthumb5 crashes
D6008111 testthumb6
D600811D testthumb7
D6008127 testthumb8
那么这一切是做什么的，它与您的问题有什么关系.这与通过拇指模式(以及更简单的手臂)进行的混合模式调用有关.
So what is all of this doing and what does it have to do with your question. This has to do with mixed mode calling from thumb mode (and also from arm which is simpler)
我已经在此级别上对ARM和Thumb模式进行编程多年了，并且一直以来都存在这种错误.我以为程序计数器始终保持该模式在lsbit中，我知道您知道在执行bx指令时要设置还是不设置它.
I have been programming ARM and thumb mode at this level for many years, and somehow have had this wrong all along. I thought the program counter always held the mode in that lsbit, I know as you know that you want to have it set or not set when you do a bx instruction.
在《 ARM体系结构参考手册》中非常早地介绍了ARM处理器的CPU(如果您正在编写汇编程序，则应该已经有了，否则，大多数问题都将得到解答.)
Very early in the CPU description of the ARM processor in the ARM Architectural Reference Manual (if you are writing assembler you should already have this, if not maybe most of your questions will be answered).
Program counter Register 15 is the Program Counter (PC). It can be used in most
instructions as a pointer to the instruction which is two instructions after
the instruction being executed...
因此，让我们检查一下它的真正含义是什么，在arm模式下，这意味着两个指令，前8个字节?在拇指模式下，前面两个指令还是前面4个字节?
So let's check and see what that really means, does that mean in arm mode two instructions, 8 bytes ahead? And in thumb mode, two instructions ahead, or 4 bytes ahead?
因此，testarm验证程序计数器在前8个字节.这也是两条指令.
So testarm verifies that the program counter is 8 bytes ahead. Which is also two instructions.
testthumb1验证程序是否在前面4个字节，在这种情况下，它也是两条指令.
testthumb1 verifies that the program is 4 bytes ahead, which in this case is also two instructions.
testthumb2:
d60080d2: 4678 mov r0, pc
d60080d4: f7ff fffb bl d60080ce <bounce>
d60080d8: 4710 bx r2
如果程序计数器前面有两个指令"，我们将得到0xD60080D8，但我们得到的是前面4个字节的0xD60080D6，这更有意义. Arm模式提前8个字节，Thumb模式提前4个字节，不会干扰正在执行的代码之前的解码指令(或数据)，只需加4或8.
If the program counter was two "instructions" ahead we would get 0xD60080D8 but we instead get 0xD60080D6 which is four bytes ahead, and that makes a lot more sense. Arm mode 8 bytes ahead, thumb mode 4 bytes ahead, no messing with decoding instructions (or data) that are ahead of the code being executed, just add 4 or 8.
testthumb3希望mov lr,pc很特别，不是.
如果您还没有看到该模式，则未设置程序计数器的lsbit，我想这对于分支表来说是有意义的.因此，mov lr,pc在拇指模式下不会正确设置链接寄存器以进行返回.
If you don't see the pattern yet, the lsbit of the program counter is NOT set, and I guess this makes sense for branch tables for example. So mov lr,pc in thumb mode does NOT set up the link register right for a return.
testthumb4会以非常痛苦的方式将程序计数器带到该代码恰好结束的地方，并根据精心放置的指令来计算返回地址.必须返回添加.现在为什么我们不能做这样的事情:
testthumb4 in a very painful way does take the program counter wherever this code happens to end up and based on carefully placed instructions, computes the return address, if you change that instruction sequence between mov r1,pc and bx r2 you have to return the add. Now why couldn't we just do something like this:
add r1,pc,#1
bx r2
使用thumb指令不能，而使用thumb2则可以.而且似乎有些处理器(armv7)同时支持arm指令和thumb/thumb2，因此您可能会想要这样做.但是您不会添加#1，因为thumb2 add指令是一个4字节的thumb 2指令，如果有一个允许高位寄存器且具有三个操作数的指令，则不会添加. (您需要添加#3).
With thumb instructions you can't, with thumb2 you probably could. And there appear to be some processors (armv7) that support both arm instructions and thumb/thumb2 so you might be in a situation where you would want to do that. But you wouldn't add #1 because a thumb2 add instruction, if there is one that allows upper registers and has three operands would be a 4 byte thumb 2 instruction. (you would need to add #3).
所以testthumb5直接来自我向您展示的代码，该代码导致了该问题的一部分，并且崩溃了.这不是它的工作方式，对不起，我误导了人们，我将尝试回过头来解决与之相关的SO问题.
So testthumb5 is directly from the code I showed you that lead to part of this question, and it crashes. This is not how it works, sorry I mislead folks I will try to go back and patch up the SO questions I used this with.
testthumb6是一个实验，以确保我们都没有疯狂.一切都很好，链接寄存器确实确实设置了lsbit，因此稍后您bx lr时，它从该位知道模式.
testthumb6 is an experiment to make sure we are all not crazy. All is well the link register does indeed get the lsbit set so that when you bx lr later it knows the mode from that bit.
testthumb7，这是从ARM侧蹦床派生的，您看到链接器从手臂模式切换到拇指模式时所做的事情，在这种情况下，尽管我正在从拇指模式切换到手臂模式.链接器为什么不能这样做?因为至少在拇指模式下，您必须使用一个低位寄存器，因此在游戏的这一点上，编译代码后，链接器无法知道它可以丢弃的寄存器.在arm模式下，尽管ip寄存器(不确定r12)可能会被破坏，我猜想它是保留给编译器使用的.我知道在这种情况下，r1可能会被破坏并使用它，并且可以按需工作.调用armbounce代码，该代码将获取链接寄存器(如果要返回的位置)，这是testthumb7函数中bl armbounce_thumb之后的拇指指令(lsbit set)，恰好是我们想要的位置.
testthumb7, this is derived from the ARM side trampoline that you see the linker doing when going from arm mode to thumb mode, in this case though I am going from thumb mode to arm mode. Why can't the linker do it this way? Because in thumb mode at least you have to use a low register and at this point in the game, after the code is compiled the linker has no way of knowing what register it can trash. In arm mode though the ip register, not sure what that is maybe r12, can get trashed, I guess it is reserved for the compiler to use. I know in this case that r1 can get trashed and used it, and this works as desired. The armbounce code gets called which grabs the link register if where to return to, which is a thumb instruction (lsbit set) after the bl armbounce_thumb in the testthumb7 function, exactly where we wanted it to be.
testthumb8这是gnu链接器在需要从拇指模式切换到手臂模式时的处理方式. bl指令设置为转到蹦床.然后他们做了一些非常棘手的事情，看上去很疯狂:
testthumb8 this is how the gnu linker does it when it needs to get from thumb mode to arm mode. The bl instruction is set to go to a trampoline. Then they do something very very tricky, and crazy looking:
d6008140 <armbounce_thumb_two>:
d6008140: 4778 bx pc
d6008142: 46c0 nop ; (mov r8, r8)
d6008144: eaffffdc b d60080bc <armbounce>
A bx pc.从上面的实验中我们知道pc在前面四个字节，我们还知道lsbit未设置.因此，这就是分支到该代码后四个字节的ARM代码. nop是一个两个字节的分隔符，然后我们必须生成一个ARM指令，该指令要提前四个字节并在四个字节边界上对齐，并且我们将无条件转移到我们要去的任何地方，这可能是某物或某物. ldr pc，=取决于您需要走多远.非常棘手.
A bx pc. We know from the experiments above that the pc is four bytes ahead, we also know that the lsbit is NOT SET. So what this is saying is branch to the ARM CODE that is four bytes after this one. The nop is a two byte spacer, then we have to generate an ARM instruction four bytes ahead AND ALIGNED ON A FOUR BYTE BOUNDARY, and we make that an unconditional branch to whatever place we were going, this could be a b something or a ldr pc,=something depending on how far you need to go. Very tricky.
原始的bl arm_bounce_thumb_two设置链接寄存器以返回该bl之后的指令.蹦床不修改链接寄存器，只执行分支.
The original bl arm_bounce_thumb_two sets up the link register to return to the instruction after that bl. The trampoline does not modify the link register it simply performs branches.
如果要从手臂进入拇指模式，请执行链接器的操作:
If you want to get to thumb mode from arm then do what the linker does:
...
bl myfun_from_arm
...
myfun_from_arm:
ldr ip,[pc]
bx ip
.word myfun
这样做的时候看起来是这样的(从另一个二进制文件(不是位于0xD6008xxx而是位于0x0001xxxx处获取).
Which looks like this when they do it (grabbed from a different binary not at 0xD6008xxx but at 0x0001xxxx).
101f8: eb00003a bl 102e8 <__testthumb1_from_arm>
000102e8 <__testthumb1_from_arm>:
102e8: e59fc000 ldr ip, [pc] ; 102f0 <__testthumb1_from_arm+0x8>
102ec: e12fff1c bx ip
102f0: 00010147 andeq r0, r1, r7, asr #2
所以不管这个IP寄存器是什么(r12?)，他们都不介意对其进行垃圾回收，我想欢迎您自己对其进行垃圾回收.
So whatever this ip register is (r12?) they don't mind trashing it and I assume you are welcome to trash it yourself.
这篇关于在Thumb代码中使用BX调用Thumb函数，或在另一个函数中跳转到Thumb指令的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
