Ich stehe vor einem seltsamen Problem, ähnlich wiediese. Ich habe ein natives Windows Phone 8-DLL-Projekt, meistens C ++, aber mit einer ARM-Assembly-Quelle. Die Quelle befindet sich im ARM-Modus (d. H. Nicht Thumb). C ++ wird zu Thumb kompiliert.

Die App stürzt ab, wenn C ++ versucht, eine Assembly-Routine aufzurufen. Der Aufrufbefehl in der Disassemblierung ist BLX mit einem sofortigen Offset - er soll bedingungslos in den ARM-Modus zurückkehren, tut dies aber irgendwie nicht.

Ich habe die Details der Ausnahme. Der Ausnahmecode ist 0xc000001d (ungültige Operation) und der Wert des PCs in der Absturzkontextstruktur ist 0x696d5985. Das ist in beiden Modi unmöglich - es ist falsch ausgerichtet, Bit Null ist Eins. Der BLX-Befehl geht1b f0 0c eb - Wenn Sie entschlüsseln, ist das ein zweiteiliger BLX im Daumenstil mit einer Verschiebung von 4 Linien. Das T-Flag im Absturzkontext ist SET (CPSR = 0x60000010).

Ich habe kein Gerät, aber das Absturzprotokoll eines Betatesters ist ziemlich aussagekräftig. Ich habe einen Debug-Protokollsatz direkt vor dem Aufruf der Assembly. Dann der Absturz.

BEARBEITEN:verbunden . Sie behaupten jedoch, dass der Assembler selbst (armasm) übersetzt ARM in Thumb. Das ist bei mir nicht der Fall - zumindest nicht statisch. Die DLL enthält den richtigen ARM-Code, wie in der Assembly-Quelle angegeben (CODE32).

BEARBEITEN: versucht mit einer etwas anderen Sprungsequenz:

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.

Gleiches Ergebnis. Es sieht so aus, als ob irgendwo im Store seltsames Code-Morphing stattfindet oder das Betriebssystem selbst Modi-Schalter abfängt und diese verhindert.

Code-Morphing kann wahrscheinlich erkannt werden, indem Teile der ausführbaren Datei zusammen mit den restlichen Absturzdaten in das Absturzprotokoll geschrieben werden. Aber was kann ich mit Betriebssystemstörungen tun, wenn ich nicht die gesamte Codebasis in Thumb konvertiere? Es wird nicht einfach neu kompiliert.

EDIT for dwelch: Die Aufrufreihenfolge im kompilierten C-Code sieht folgendermaßen aus:

.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 an eine sofortige Adresse MUSS den Modus wechseln. Es ist nicht bedingt, wiebx register. Das Anrufziel ist ein Thunk:

.text:10025984                 B               Func_Impl

Und die Absturzadresse ist dieser Thunk plus eins: 5985.

Dies ist eine Demontage einer kompilierten DLL, aber ich kann nicht garantieren, dass genau dies auf einem Gerät ausgeführt wird. Der Benutzer in einem verknüpften MSDN-Thread gab an, die Demontage untersucht zu habenim Debugger und sah Thumb, wo ARM hätte sein sollen. Microsoft, IIRC, hält ein Patent für die Änderung von App-Codeunterwegs vom Verlag zum Gerät; Das könnte der Grund sein.