是ARM（不拇指）支持WinPhone8呢？ [英] Is ARM (not Thumb) supported on WinPhone8 at all?

问题描述

我现在面临一个奇怪的问题，有点类似<一个href=\"http://stackoverflow.com/questions/13488620/arm-neon-assembly-on-windows-phone-8-not-working\">this.我有一个Windows Phone 8的本地DLL项目，主要是C ++，但在它的ARM汇编源。来源是ARM模式（即不拇指）。 C ++编译为Thumb。

I'm facing a weird issue, somewhat similar to this. I have a Windows Phone 8 native DLL project, mostly C++ but with an ARM assembly source in it. The source is in ARM mode (i. e. not Thumb). C++ is compiled to Thumb.

在C ++尝试调用到一个汇编程序的应用程序崩溃。在反汇编的调用命令是与BLX立即偏移 - 它应该切换模式切换回ARM，无条件的，但不知何故，没有

The app crashes when C++ tries to call into an assembly routine. The call command in the disassembly is BLX with an immediate offset - it's supposed to switch mode back to ARM, unconditionally, but somehow it doesn't.

我有异常的详细信息。唯一的例外code为0xc000001d（无效操作），并在碰撞情况下结构中的PC的值是0x696d5985。这两种模式下是不可能的 - 这是错位，位零就是其中之一。该BLX指令进入 1B F0 0℃EB - 如果你破译，这是一个两部分拇指式BLX没事，有4对齐偏移。在事故情况下的T标志被设置（CPSR = 0x60000010）。

I have the details of the exception. The exception code is 0xc000001d (invalid operation), and the value of the PC in the crash context struct is 0x696d5985. That's impossible in either mode - it's misaligned, bit zero is one. The BLX instruction goes 1b f0 0c eb - if you decipher, that's a two-part Thumb-style BLX all right, with a 4-aligned displacement. The T flag in the crash context is SET (CPSR=0x60000010).

我没有设备，但是从beta测试崩溃日志为pretty定论。我该呼叫转变装配前右侧有一个调试日志记录。然后崩溃。

I don't have a device, but the crash log from a beta tester is pretty conclusive. I have a debug log record right before the call into assembly. Then the crash.

编辑：<一href=\"http://social.msdn.microsoft.com/Forums/wpapps/en-us/3cfafda3-9f1c-418c-b9db-78da844d4398/unable-to-execute-arm-assembly-$c$c-in-the-arm-instruction-set-statealways-in-the-default-thumb\"相对=nofollow>相关。他们声称，然而，汇编程序本身（则armasm ）转换ARM到Thumb。这不是我的情况 - 至少不是静态。该DLL包含适当的ARM code，在汇编源指定的（ code32 ）。

related . They claim, however, that the assembler itself (armasm) translates ARM to Thumb. That's not the case for me - at least not statically. The DLL contains proper ARM code, as specified in the assembly source (CODE32).

编辑：有一个稍微不同的跳跃序列的尝试：

tried with a slightly different jump sequence:

ldr r12, target
and r12, r12, #0xfffffffe ; To be sure
bx r12 ;BX to a register with a cleared 0th bit. Doesn't get any more explicit than that.

同样的结果。看起来像有在商店要么有些怪异code变形发生的地方，或者操作系统本身捕捉模式开关和prevents他们。

Same result. Looks like there's either some weird code morphing taking place somewhere in the Store, or the OS itself catches mode switches and prevents them.

code变形也许可以通过倾销可执行部分的碰撞数据的其他部分一起到崩溃日志来检测。但我可以做OS的干扰，短期内恐难为整个codeBase类，以拇指？它不只是重新编译。

Code morphing can probably be detected by dumping portions of the executable into the crash log along with rest of the crash data. But what can I do with OS interference, short of converting to whole codebase to Thumb? It doesn't just recompile.

编辑dwelch：在编译的C code调用顺序是这样的：

EDIT for dwelch: the calling sequence in compiled C code goes like this:

.text:1000A35E                 MOV             R2, #g_Host ;Three parameters
.text:1000A366                 MOV             R1, R5
.text:1000A368                 MOV             R0, R6
.text:1000A36A                 BLX             Func ; Code bytes 1B F0 0C EB

BLX到立即地址切换模式。这不是有条件的，如 BX寄存器。呼叫目标是一个thunk：

BLX to an immediate address HAS to switch mode. It's not conditional, like bx register. The call target is a thunk:

.text:10025984                 B               Func_Impl

和崩溃的地址是这样的thunk加一：5985

And the crash address is this thunk plus one: 5985.

这是一个编译的DLL的拆卸，但我不能保证这正是一个设备上执行。在链接的MSDN线程的用户称，他们期待在调试器拆装的 并看到拇指ARM的地方应该去过。微软，IIRC，适用于应用程序修改code的途中专利的从发行到设备;这可能是原因。

This is a disassembly of a compiled DLL, but I have no guarantee that this is exactly what's executing on a device. The user in a linked MSDN thread claimed that they looked at the disassembly in the debugger and saw Thumb where ARM should've been. Microsoft, IIRC, holds a patent for modifying app code en route from publisher to device; that could be the reason.

推荐答案

我有这种第一手知识;我是谁在Windows RT的内核想通了事业的逆向工程。具体来说， KeContextFromKframes 在Windows NT内核（ ntoskrnl.exe中）的设置 T 冻结位当一个线程的状态任务切换。这意味着，是的，​​在中断后恢复，你会崩溃。

I have firsthand knowledge of this; I was the reverse engineer who figured out the cause in Windows RT's kernel. Specifically, KeContextFromKframes in the Windows NT kernel (ntoskrnl.exe) is setting the T bit when freezing a thread's state for a task switch. This means that yes, upon resuming after an interrupt, you will crash.

这让我们很生气越狱的RT / WinPhone，因为我们不能直接端口Chrome的抖动不会破坏微软的PatchGuard技术。我们可以加载内核驱动程序修补了这一点 KeContextFromKframes ，但后来PatchGuard技术以后会导致崩溃。

This annoyed us jailbreakers for RT/WinPhone, because we couldn't directly port Chrome's JITter without breaking Microsoft's PatchGuard. We could load a kernel driver to patch this out of KeContextFromKframes, but then PatchGuard would later cause a crash.

这篇关于是ARM（不拇指）支持WinPhone8呢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！