問題タブ [kgdb]

デバッグ情報と KGDB を使用して、arm のカーネル ソースをクロス コンパイルしました。

ホストで gdb を実行すると:

関数にブレークポイントを設定しようとすると、GDB は関数を認識しないと言います。例:

助けてください ！！

Nexus 5 のカーネルをデバッグしています。非常にバグが多く、電話が正常に起動しないほどです。多くのバグがあります。オーディオジャックを介してKGDBでデバッグしたいと思います（シリアルポートであるため）。カーネルをコンパイルして kgdb を有効にする方法は既に学習しましたが、カーネル パニックが発生する前に minicom を介してカーネルの実行を停止できないため、まだ機能しません。どうすれば KGDB を機能させることができますか?

arm64 カーネルをデバッグするために KGDB をセットアップしようとしています。私のセットアップは、ターゲットがカーネル 3.14 (いくつかの arm64 kgdb パッチがバックポートされた状態) で実行され、ホストで linaro ツールチェーン 4.8 aarch64-linux-gnu-gdb を使用し、発行するたびに:

エラーメッセージが表示されました：

私はこの問題について多くのことをグーグルで検索しましたが、どれもうまくいきませんでした。この問題はarm64に固有のものだと思います。ひょっとして、ここにいる誰かが先に進む方法を知っていますか?

現在、KGDB を使用してカーネル コードをデバッグしています。割り込むたびに、自然に kgdb の割り込みハンドラにジャンプします。GDB の下で、次のコマンドを実行しました。

出力は次のようになります

7 スレッド 7 (rcu_sched) 0x0000000000000000 in irq_stack_union ()

6 スレッド 5 (kworker/0:0H) 0x0000000000000000 in irq_stack_union ()

5 スレッド 3 (ksoftirqd/0) 0x0000000000000000 in irq_stack_union ()

4 スレッド 2 (kthreadd) 0x0000000000000000 in irq_stack_union ()

3 スレッド 1 (init) 0x0000000000000000 in irq_stack_union ()

2 スレッド 3754 (Xorg) 0x0000000000000000 in irq_stack_union ()

• 1 スレッド 4294967294 (shadowCPU0) kgdb_breakpoint ()

  kernel/debug/debug_core.c:1042 で

次に、別のスレッドで終了することを期待してコードをジャンプします（Xorgに興味があります）が、コードをステップ実行した後、次の実行中のスレッドがCPUアイドルになります。

• 1 スレッド 4294967294 (shadowCPU0) cpu_idle_loop () カーネル/cpu/idle.c:116 で

デバッグ コンテキストを Xorg または他のスレッドに切り替えるにはどうすればよいですか。さらに、irq_stack_union () の意味は何ですか。スレッドは保留中の割り込みでアイドル状態ですか?

私のカーネルのバージョンは 2.6.35 です。kgdb 2.6.35 がオンラインで見つかりません。

どのバージョンの kgdb を使用できるか、誰にもわかりませんか?

kgdb / リモート gdb を使用して Linux ubuntu カーネルをデバッグしています。ubuntuターゲットとWindowsホストの2台のコンピューターがあります。コンピュータは、シリアル ポートとヌル モデム ケーブルを使用して接続されます。

KGDB のサポートは、ターゲットの ubuntu システムで有効になっています。KGDB のコマンド オプションは次のとおりです。

kgdbwait kgdboc=ttyS0,115200

私の Windows システムには、MinGW gdb ビルド (x86_64) があります。

GNU gdb (GDB) 7.4 Copyright (C) 2012 Free Software Foundation, Inc. この GDB は「x86_64-w64-mingw32」として構成されていました。

ターゲット システムを起動すると、リモート デバッガーが接続されるまで待機します。GDB ウィンドウに次のコマンドを入力します。

私のgdbはターゲットに接続でき、次を出力します：

kernel/debug/debug_core.c:1043 wmb(); でCOM4 ???() を使用したリモート デバッグ。/* ブレークポイント後の同期ポイント */

次に、OS の起動時に gdb に戻れるようにブレークポイントを設定するコマンドを入力します。

0xffffffff8124a710 のブレークポイント 1

同じセットアップの別の実行で、ハードウェア支援のブレークポイントも試しました。

このブレークポイントの設定により、ターゲットの ubuntu コンソールから sync コマンドを入力すると、カーネル ビークがデバッガに戻るはずです。

GDBで続行を押した後、OSは正常に起動しますが、制御をgdbに戻すことはできません。sys_sync にブレークポイントを設定してみました。

すべての場合で成功しません。

非常に興味深い: 最初に sys_sync にブレークポイントを設定しないと、後で sync コマンドを入力しても何も起こりません。sys_sync ブレークポイントを設定すると、後で sync コマンドを入力すると、ターゲット コンピューターが完全に停止するため、この場合、ブレークポイントが実際に設定されていると思います。

デバッガーに侵入するには? GDB は CTrl-C コマンドに応答しなくなるため、最初に [続行] を押した後にデバッグを続行する方法はありません。

アーキテクチャの非互換性 (Windows gdb - Linux ターゲット) の可能性がありますが、実際にはブレークポイントが設定されているようです。

助けてください