Gdbが内部でどのように機能するのか知りたいです。例えばトレースされたプログラムを監視するためにptrace()システムコールを利用するという簡単なアイデアを知っています。しかし、シグナルをどのように処理するか、新しいコードをどのように挿入するか、その他のすばらしいことを知りたいです。
GDB Internals Manual をチェックしてください。これは、いくつかの重要な側面をカバーしています。このドキュメントの古い PDFバージョン もあります。
マニュアルから:
このドキュメントでは、GNUデバッガー、gdbの内部について説明します。これには、gdbの主要なアルゴリズムと操作、およびgdbを特定のホストとターゲットに適合させるメカニズムの説明が含まれています。
Gdbint.pdfから取得:
これは、ハードウェアブレークポイントまたはソフトウェアブレークポイントとして実行できます。
- ハードウェアブレークポイントは、一部のチップに組み込まれたデバッグ機能として利用できる場合があります。通常、これらはブレークポイントアドレスを格納できる専用レジスタを持つことで機能します。 PC(プログラムカウンタの省略形)がブレークポイントレジスタの値と一致する場合、CPUは例外を発生させ、それをGDBに報告します。
- もう1つの可能性は、エミュレーターが使用されている場合です。多くのエミュレータには、プロセッサから出てくるアドレスラインを監視し、アドレスがブレークポイントのアドレスと一致した場合にプロセッサを強制的に停止する回路が含まれています。
- 3番目の可能性は、ターゲットがすでに何らかの方法でブレークポイントを実行する機能を持っていることです。たとえば、ROMモニターは、独自のソフトウェアブレークポイントを実行する場合があります。したがって、これらは文字通りハードウェアブレークポイントではありませんが、GDBの観点からは同じように機能します。
- ソフトウェアブレークポイントでは、GDBがいくらか多くの作業を行う必要があります。基本的な理論では、GDBはプログラム命令をトラップ、不正な除算、または例外を引き起こすその他の命令に置き換え、それが発生すると、GDBは例外を取得してプログラムを停止します。ユーザーが続行するように言うと、GDBは元の命令を復元し、シングルステップでトラップを再挿入して続行します。
あなたが見つける唯一の方法は ソース を研究することです。
また、それをビルドして、それ自体でデバッグすることもできます。コードをステップスルーすると、正確にコードがどのように機能するかがわかります。
ただし、GDBソースを読み取ることは、気の弱い人向けではありません。マクロがぎっしり詰まっていて、libbfd
を多用しますが、それ自体は理解しにくいものです。
移植可能であるため(特に、ptrace()
がまったくないプラットフォームでビルドおよび動作するため)、そうする必要があります。