ARM ターゲット [x86] の 1 つで奇妙なクラッシュに直面しています。Windbg のクラッシュは、不正なメモリ アクセスを示します。
ドライバー_IRQL_NOT_LESS_OR_EQUAL (d1)
高すぎる割り込み要求レベル (IRQL) で、ページング可能な (または完全に無効な) アドレスにアクセスしようとしました。これは通常、ドライバが不適切なアドレスを使用していることが原因です。
引数: Arg1: 00000000、メモリ参照
Arg2: 00000002、IRQL
Arg3: 00000000、値 0 = 読み取り操作、1 = 書き込み操作
Arg4: 8849fe99、メモリを参照したアドレス
これは、命令 0x8849fe99 でメモリ 0x00000000 にアクセスしようとしていることを明確に示しています。0x8849fe99 コードを逆アセンブルすると、次のようになります。
8849fe98 8818 ldrh r0,[r3]
ダンプ show を登録します。
r0=00000000 r1=8458ac70 r2=00000000 r3=00000000 r4=00000000 r5=00000000
r6=00000000 r7=00000000 r8=00000000 r9=00000000 r10=00000000 r11=8458ac20
r12=b7edbed9 sp=8458ac18 lr=8849fe8b pc=8849fe98 psr=400000b3 -Z--- Thumb
8849fe98 8818 ldrh r0,[r3] 00000000=????
だから、私はR3でメモリの内容にアクセスしようとしていました-しかし、R3は0x0000000です-完全に論理的です。
しかし、ここで楽しい部分が来ます.. 私はメモリの周りのコードをチェックして、次の逆アセンブリを見つけようとします.
8849fe94 4620 mov r0,r4
8849fe96 e8bd8818 pop {r3,r4,r11,pc}
8849fe9a 0000 movs r0,r0
8849fe9c 0000 movs r0,r0
8849fe9e 0000 movs r0,r0
上記のコードから、0x8849FE96 のコードは 32 ビット命令であり、一度に実行されるはずであることがわかります。
しかし、デバッガーは、(0x8849FE98 で) 16 ビット命令を実行しようとしたことを示しています - これはまったく予期されていません!!
明らかに、有効な操作を行う 32 ビット命令がありますが、なぜ ARM はそれを 16 ビット命令と見なし、正常な命令 [e8bd8818] を 2 つに分割して 16 ビット命令 [8818] を実行するのですか?
コードはTHUMBモードで実行されています。つまり、プロセッサは、いつ16ビットモードで命令を実行し、いつ32ビットモードで命令を実行する必要があるかを知る必要があります。
プロセッサが命令を 16 ビットと見なしているのはなぜですか?