1

カーネル モードとユーザー モードの両方の目的と、前者から後者への遷移がどのように発生するかを理解しています。しかし、多くの情報源は、カーネル モードで発生するクラッシュはデバッグが難しく、たとえば telnet 経由で接続してリモートで実行する必要があると述べています (ここに例があります)。

デバッグが難しいのはなぜですか？(カーネル) デバッガーをカーネル スレッドの 1 つに接続して、通常の方法で使用できないのはなぜですか?

4

2 に答える 2

4

カーネル モードでクラッシュすると、メモリ内の任意の場所でデータ構造が破損する可能性があります。デバッガー自体も破損する可能性があります。その防弾を作るのは難しいです。

通常のデバッグでは、デバッガーとデバッグ対象の 2 つの完全に分離されたプロセスがあります。彼らは「仲間」であり、平等に作られています。デバッグ中のプロセスは、デバッガが何をしていても、デバッガに触れることはできません (おそらく、デバッガが存在することすら知りません)。一方、デバッガーは、すべての通常のユーザー プロセスに常に適用できる固定された予測可能な方法で、デバッグ中のプロセスと対話できます。

例: ローカル デバッグの場合はキーボード インターフェイスを、シリアル ポート経由の場合は RS232 コードをどのようにデバッグしますか? ネットワーク上にある場合は、NIC ドライバーまたはネットワーク スタック? これらのいずれかにブレークポイントを設定すると、デバッガーを制御するデバイスにアクセスできなくなるため、回復できなくなります。最悪の場合、カーネル デバッガーをどのようにデバッグしますか? GDB を使用すると、少なくとも理論的には、GDB インスタンスを GDB の別のインスタンスにあまり問題なくアタッチできます。カーネル空間では、物事を仲介する層が上にないため、それは不可能です。

于 2012-01-05T17:59:53.963 に答える
0

カーネル自体が (適切なディスプレイ ドライバーと通信することによって) モニターに画像を表示することも担当しているため、カーネルを対話的に (またはローカルに) デバッグすることはできません。私はあなたの質問を別の言い方にします: telnet 経由で接続するよりも簡単にカーネルをデバッグすることは可能ですか?

その質問に対する私の答えは: はい、そうです。仮想化を使用して、少なくとも X86/X64 アーキテクチャで。VirtualBox を使用して、ローカル マシンでデバッグできるゲスト OS を実行しています。また、VirtualKD (http://virtualkd.sysprogs.org/) を使用しています。これにより、デバッグ マシン (ホスト) と VM の間の通信が大幅に高速化されます。

VirtualKD には、ゲスト Windows の boot.ini を変更するパッケージが含まれているため、Windows が表示する適切なメニュー項目を選択することで、起動時にデバッグを有効にすることができます。

于 2012-01-10T10:25:58.370 に答える