もう 1 つのオプションは、ICE/JTAG コントローラーと GDB を使用することです。この「ハードウェア」ソリューションは、組み込みシステムで特に使用されます。
しかし、例えば Qemu は同様の機能を提供しています:
-
'localhost:1234' でリッスンする gdb 'remote' スタブで qemu を起動します:
qemu -s ...、 -
次に、GDB でカーネル ファイル
vmlinuxを開きます。 デバッグ情報とともにコンパイルされています (カーネルの非最適化について議論しているこのメーリング リストのスレッドを参照してください)。 -
GDB と Qemu を接続:
target remote localhost:1234 -
ライブを見る カーネル:
(gdb) where #0 cpu_v7_do_idle () at arch/arm/mm/proc-v7.S:77 #1 0xc0029728 in arch_idle () atarm/mach-realview/include/mach/system.h:36 #2 default_idle () at arm/kernel/process.c:166 #3 0xc00298a8 in cpu_idle () at arch/arm/kernel/process.c:199 #4 0xc00089c0 in start_kernel () at init/main.c:713
残念ながら、GDB ではこれまでのところユーザー空間のデバッグはできません (タスク リスト情報がない、さまざまなプロセス コンテキストを確認するための MMU 再プログラミングがないなど) が、カーネル空間にとどまる場合は非常に便利です。
info threadsさまざまな CPU のリストと状態が表示されます
編集:
手順の詳細については、この PDF を参照してください:
<ブロック引用>GDB と QEMU を使用した Linux システムのデバッグ
Linux カーネルのデバッグ中に、デバッガー (KDB、KGDB)、クラッシュ時のダンプ (LKCD)、トレース ツールキット (LTT、LTTV、LTTng)、カスタム カーネル インストゥルメント (dprobes、kprobes) など、いくつかのツールを利用できます。次のセクションでは、それらのほとんどを要約しようとしました。これらが役立つことを願っています.
LKCD (Linux Kernel Crash Dump) ツールを使用すると、クラッシュが発生したときに Linux システムがメモリの内容を書き込むことができます。これらのログは、クラッシュの根本原因についてさらに分析できます。 LKCD に関するリソース
- http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaax/lkcd.pdf
- https://www.novell.com/coolsolutions/feature/15284.html
- https://www.novell.com/support/kb/doc.php?id=3044267
おっと カーネルが問題を検出すると、Oops メッセージを出力します。このようなメッセージは、障害ハンドラ (arch/*/kernel/traps.c) の printk ステートメントによって生成されます。 printk ステートメントによって使用されるカーネル内の専用リング バッファー。 Oops には、Oops が発生した CPU、CPU レジスタの内容、Oops の数、説明、スタック バック トレースなどの情報が含まれます。カーネル Oops に関するリソース
- https://www.kernel.org/doc/Documentation/oops-tracing.txt
- http://madwifi-project.org/wiki/DevDocs/KernelOops
- https://wiki.ubuntu.com/DebuggingKernelOops
動的プローブ IBM が開発した Linux 用の人気のあるデバッグ ツールの 1 つです。このツールを使用すると、ユーザー空間とカーネル空間の両方で、システムのほぼすべての場所に「プローブ」を配置できます。プローブは、制御が特定のポイントに達したときに実行されるコード (特殊なスタック指向の言語で記述された) で構成されます。以下にリストされている動的プローブに関するリソース
- http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaax/dprobesltt.pdf
- http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.107.6212&rep=rep1&type=pdf
Linux トレース ツールキット カーネル パッチと、カーネル内のイベントのトレースを可能にする一連の関連ユーティリティです。トレースにはタイミング情報が含まれており、一定期間に何が起こったのかをある程度完全に把握できます。 LTT、LTT Viewer、LTT Next Generation のリソース
- http://elinux.org/Linux_Trace_Toolkit
- http://www.linuxjournal.com/article/3829
- http://multivax.blogspot.com/2010/11/introduction-to-linux-tracing-toolkit.html
MEMWATCH オープン ソースのメモリ エラー検出ツールです。 gcc ステートメントで MEMWATCH を定義し、コードにヘッダー ファイルを追加することで機能します。これにより、メモリリークとメモリ破損を追跡できます。 MEMWATCHに関するリソース
- http://www.linuxjournal.com/article/6059
ftrace Linux カーネルの優れたトレース フレームワークです。 ftrace は、カーネルの内部操作をトレースします。このツールは、2.6.27 の Linux カーネルに含まれています。さまざまなトレーサー プラグインを使用して、ftrace はさまざまな静的トレースポイント (スケジュール イベント、割り込み、メモリ マップ I/O、CPU 電源状態の遷移、ファイル システムや仮想化に関連する操作など) をターゲットにすることができます。また、カーネル関数呼び出しの動的追跡が利用可能で、オプションでグロブを使用して関数のサブセットに制限でき、呼び出しグラフを生成してスタック使用を提供する可能性があります。 https://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_rostedt.pdf で ftrace の優れたチュートリアルを見つけることができます
ltrace Linux のデバッグ ユーティリティであり、ユーザー空間アプリケーションが共有ライブラリに対して行った呼び出しを表示するために使用されます。このツールを使用して、任意の動的ライブラリ関数呼び出しをトレースできます。実行されたプロセスによって呼び出された動的ライブラリ呼び出しと、そのプロセスによって受信されたシグナルを傍受して記録します。また、プログラムによって実行されるシステム コールをインターセプトして出力することもできます。
- http://www.ellexus.com/getting-started-with-ltrace-how-does-it-do-that/?doing_wp_cron=1425295977.1327838897705078125000
- http://developerblog.redhat.com/2014/07/10/ltrace-for-rhel-6-and-7/
KDB Linux カーネルのカーネル内デバッガです。 KDB は単純なシェル スタイルのインターフェイスに従います。これを使用して、メモリ、レジスタ、プロセス リスト、dmesg を検査し、特定の場所で停止するようにブレークポイントを設定することもできます。 KDB を介して、ブレークポイントを設定し、いくつかの基本的なカーネル実行制御を実行できます (ただし、KDB はソース レベルのデバッガーではありません)。 ）。 KDB に関するいくつかの便利なリソース
- http://www.drdobbs.com/open-source/linux-kernel-debugging/184406318
- http://elinux.org/KDB
- http://dev.man-online.org/man1/kdb/
- https://www.kernel.org/pub/linux/kernel/people/jwessel/kdb/usingKDB.html
KGDB Linux カーネルのソース レベル デバッガーとして使用することを目的としています。これは Linux カーネルをデバッグするために gdb と共に使用されます。 kgdb を使用するには、2 台のマシンが必要です。これらのマシンの 1 つは開発マシンで、もう 1 つはターゲット マシンです。デバッグ対象のカーネルは、ターゲット マシン上で実行されます。アプリケーション開発者が gdb を使用してアプリケーションをデバッグするのと同じように、gdb を使用してカーネルに「侵入」し、メモリ、変数を検査し、コール スタック情報を調べることができると期待されています。カーネル コードにブレークポイントを配置して、限定的な実行ステップを実行することができます。 KGDB に関するいくつかの便利なリソース
- http://landley.net/kdocs/Documentation/DocBook/xhtml-nochunks/kgdb.html
ウィキによると、kgdb 2.6.26 でカーネルにマージされました ここ数年以内のものです。 kgdb はリモート デバッガーであるため、カーネルでアクティブ化してから、何らかの方法で gdb をアタッチします。多くのオプションがあるように思われるので、どういうわけか言います-gdbの接続を参照してください。 kgdb を考えると は現在ソース ツリーにあります。今後はこれを使用したいと思います。
つまり、Linus は屈服したように見えます。しかし、私は彼の主張を強調したいと思います。自分が何をしているかを理解し、システムをよく知っている必要があります。これがカーネルランドです。何か問題が発生した場合、segfault は取得されません。 、後でシステム全体がダウンするというあいまいな問題から何かを得ます。ここにドラゴンがいます。注意して進めてください。警告を受けています。