macos - gdb を使用した kext のデバッグ: デッドロック

Question

I/O Kit ドライバー: 仮想イーサネット デバイスがあります。一定期間作業した後、OS がハングするため、ドライバーにデッドロックが発生しているようです。

次の手順を実行しました:
- FireWire 経由で 2 台の Macbook を接続
- デバッグ環境をセットアップ
- NMI を初期化 (電源ボタン経由)
- gdb 経由でターゲットに接続
- kext のアドレスを取得
- シンボルを作成してロード (これが最後のポイントです)私が読んだすべてのドキュメントで）
これまでのところとても良いです。カーネル パニックの場合は、これで十分です。しかし、私の場合、カーネル パニックは発生せず、NMI を処理するスレッドに常駐しています。

ここで質問: kext のスレッドに切り替えるにはどうすればよいですか?
指示showalltasksすべてのタスクのリストが表示されます.kextが実行されている唯一のタスクはkernel_taskであるため、showtaskthreadsandを介してこのタスクを調べようとしshowtaskstacksていますが、コードに似たものを見つけることができません. 何か不足していますか？

ドキュメントへの提案やリンクをいただければ幸いです。

Answer 1

さて、私は自分の質問に答えています。
kext のコードを使用してスレッドを表示するには、kext を使用するプロセスに切り替える必要があります。私の場合、おそらくブラウザになります (私の kext は NKE であるため)。

しかし、実際にはあまり役に立ちませんでした。しかし、古い印刷方法は、デッドロックを見つけるのに役立ちました。私のアドバイスは次のとおりです。カーネル パニックの場合はデバッガを使用し、デッドロックの場合は印刷を使用し、ロックの場所を見つけてコードを分析します。

Answer 2

私はあなたの質問に直接答えているわけではありませんが、ブレークポイントで kext コードをヒットすることは可能でしょうか? カーネル デバッグの一般的な方法は、マシンを nmi し、デバッガーをアタッチし、目的のコードにブレークポイントを設定し、実行を再開し ( continue)、ブレークポイントに到達するために必要なことをすべて行うことです。