WinPhone8 是否完全支持 ARM(不是 Thumb)? [英] Is ARM (not Thumb) supported on WinPhone8 at all?

问题描述

我遇到了一个奇怪的问题，有点类似于 这个.我有一个 Windows Phone 8 本机 DLL 项目，主要是 C++，但其中包含 ARM 程序集源.源处于 ARM 模式(即不是 Thumb).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.

我有异常的详细信息.异常代码为0xc000001d(无效操作)，crash context struct中PC的值为0x696d5985.这在任何一种模式下都是不可能的——它没有对齐，零位是一.BLX 指令是 1b f0 0c eb - 如果您破译，那是一个两部分的 Thumb 样式 BLX 好吧，具有 4 对齐的位移.崩溃上下文中的 T 标志为 SET (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 测试人员的崩溃日志非常有说服力.在调用程序集之前我有一个调试日志记录.然后是崩溃.

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.

related .然而，他们声称汇编程序本身 (armasm) 将 ARM 转换为 Thumb.对我来说不是这样——至少不是静态的.DLL 包含正确的 ARM 代码，如汇编源代码 (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.

同样的结果.看起来商店中某处发生了一些奇怪的代码变形，或者操作系统本身捕获了模式切换并阻止了它们.

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.

可以通过将部分可执行文件连同其他崩溃数据一起转储到崩溃日志中来检测代码变形.但是，除了将整个代码库转换为 Thumb 之外，我还能如何处理操作系统干扰?它不只是重新编译.

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 代码中的调用顺序如下:

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 register.调用目标是一个 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 应该在的 Thumb.微软，IIRC，拥有从发布者到设备修改应用程序代码途中的专利；可能是这个原因.

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 内核中找出原因的逆向工程师.具体来说，Windows NT 内核 (ntoskrnl.exe) 中的 KeContextFromKframes 会在冻结线程状态以进行任务切换时设置 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 越狱者，因为我们无法在不破坏 Microsoft 的 PatchGuard 的情况下直接移植 Chrome 的 JITter.我们可以加载一个内核驱动程序来从 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.

这篇关于WinPhone8 是否完全支持 ARM(不是 Thumb)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！