assembly - Is ARM (not Thumb) supported on WinPhone8 at all?

Question

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.

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.

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

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.

EDIT: 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).

EDIT: 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.

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.

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

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

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.

Answer 1

A gentleman called Michael Schnell suggested elsewhere that the interrupt handler in Windows Phone 8 doesn't restore the Thumb flag, instead hard-codes it to 1. Testing seems to confirm that theory. The following snippet:

    THUMB
ASMTest
    mov r12, lr
    blx a
    mov lr, r12
    bx lr

    ALIGN 4
    ARM
a
    bx lr

consistently crashes under a debugger, but runs as expected when debuggerless (i. e. no interrupts while in ARM mode). When I inserted an empty loop with 0x10000 iterations in ARM mode, it ran on a few tries, then crashed.