swap from arm to thumb mode ...

Index > Non-x86 architectures > swap from arm to thumb mode ...

Author

Thread

Gyver

Joined: 13 Jul 2009
Posts: 7

Gyver 17 Jul 2018, 16:48

Hi guys! i need your help to understand what this arm instruction really does:

"0x00010000: sub PC, PC, #1"; (we are in "Arm" mode)

Now, reading many posts, seems that instruction forces the cpu to enter in thumb mode but ... why? I know that, in Arm mode, PC is word aligned, so PC[1:0] == 0; when this instruction is executed the PC is 0x010007 ( PC = PC + 8 - 1 , this is the effect of pipeline right?). But what happen now? A "prefech abort exception" is raised ? And, above all, when the T bit is set?

Thx in advance for your help and sry for my bad english.

17 Jul 2018, 16:48

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20416
Location: In your JS exploiting you and your system

revolution 18 Jul 2018, 03:13

The lowest bit of PC tells the CPU which mode to use to decode instructions. The actual address fetched from RAM does not use the lowest bit from PC, so no exceptions are raised.

The T bit is only used when the OS is returning from an exception. In general you shouldn't change the T bit manually in code.

18 Jul 2018, 03:13

Gyver

Joined: 13 Jul 2009
Posts: 7

Gyver 18 Jul 2018, 06:09

Thx revolution! i understood, referring to my example:

0x010000: sub pc, pc #1
… entering in thumb mode…
0x010006:
… thumb code here …
right?

18 Jul 2018, 06:09

ProMiNick

Joined: 24 Mar 2012
Posts: 802
Location: Russian Federation, Sochi

ProMiNick 18 Jul 2018, 07:28

revolution wrote:

The lowest bit of PC tells the CPU which mode to use to decode instructions.

Dosn`t that apply only for earliest APM cores, where T flag was directly located in lowest pc bit, but not in flags?

sub pc,pc #1 - affect only ARM cpus where T flag is located at lowest pc bit, and flags not exist as separate entity(register).
From ARM versions where T moved to flags: instruction version without postfix "s" dosn`t affect flags.

Even more from ARMv6:
instruction variant "sub pc,reg #imm" - not exist anymore, only "subs pc,reg #imm" stayed.
instuction "sub pc, reg #imm" - In linux it is very slow form of switching to thumb mode via handling of exception generated by deprecated instruction. In other OSes it can be not handled at all.
Am I right?

_________________
I don`t like to refer by "you" to one person.
My soul requires acronim "thou" instead.

18 Jul 2018, 07:28

Gyver

Joined: 13 Jul 2009
Posts: 7

Gyver 18 Jul 2018, 07:53

Quote:

instruction "sub pc, reg #imm" - In linux it is very slow form of switching to thumb mode via handling of exception generated by deprecated instruction. In other OSes it can be not handled at all.

You are right ProMiNick! Actually this is the first instruction of an elf program Wink

18 Jul 2018, 07:53

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20416
Location: In your JS exploiting you and your system

revolution 18 Jul 2018, 09:57

ProMiNick wrote:

Dosn`t that apply only for earliest APM cores, where T flag was directly located in lowest pc bit, but not in flags?

sub pc,pc #1 - affect only ARM cpus where T flag is located at lowest pc bit, and flags not exist as separate entity(register).
From ARM versions where T moved to flags: instruction version without postfix "s" dosn`t affect flags.

The implementation could be anything. It doesn't matter to the app or the OS how the CPU implements thumb/arm mode, the instructions will still work fine.

ProMiNick wrote:

Even more from ARMv6:
instruction variant "sub pc,reg #imm" - not exist anymore, only "subs pc,reg #imm" stayed.
instuction "sub pc, reg #imm" - In linux it is very slow form of switching to thumb mode via handling of exception generated by deprecated instruction. In other OSes it can be not handled at all.
Am I right?

The switching is not handled by the OS from an exception. It is all handled by 100% the CPU. The OS won't know what mode the app is running until the next interrupt. The app could change arm/thumb mode many times and the OS would never know or care.

So I'd say that the "slowness" is not important. But as always measure it in the app if you think it is some sort of performance bottleneck. And of course different CPU implementations will have different timings so test it across all versions you intend to support.

18 Jul 2018, 09:57

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum