Debugging on ICE not on GDB Shoji Ueda (KMC) 京都マイクロコンピュータ 辻 JTAG ICEによる組み込みLINUXデバック 1. はじめに これまではデバッカというとGDB、KGDBしかなかった。 それに対し、いかにLINUXをDEBUGするかを検討してきた。 2. GDBの制限 Kernel空間で動くものは、GDBではDEBUGしにくい。 (補足:ユーザ空間にDevice DriverをもってくるとDEBUGしやすくなる。) 例えばDriverでブレークしている時に、デバック対象アプリのメモリを 見ようとしたり、はできない。 3. 技術的課題 * リロケータブルオブジェクト * デマンドページング * 仮想多重空間 4. リロケーションの解決(ローダブルモジュール) 今はローダブルモジュールをデバック用に細工している。 init.hのマクロにsoftwarebreakのコードを埋め込んでいる。 insmod時にsoftwarebreakの実行でICEに落ちる。 落ちたアドレスで.textを解決。 ICEをつないでないと、例外で止ってしまう。 この方法だと、デバック時とそれ以外での切替が大切。 5. 多重空間の解決 とても面倒くさい作業。 task_structをひたすら追い掛ける。 Kernelの中のメンバを都合の良いように書き換えることはできない。 結局何番値の命令を実行したか、しかわからない。 これを、プロセスの情報も取得し、後で見られるようにKernelのコードを修正 した。 6. デモ kernel 2.4 insmodを実行し、.text, .data, .bssが表示される。 ローダブルモジュールも普通にDEBUGできる。 Kernelでbreakしていて、これはどこのsystem callから呼ばれたか をみれる。これはGDBではできない。 標準の機能はあまり変えずに、デバックのサポートをKernelに組み込んで いきたい。 7. Linux向けの工夫 実行中のプロセスへのattach デバック情報の自動読み込み 関数トレースのプロセス対応 8. オープンソースについて Kernelの中の情報を読み込んで、ICEが解析を行うような処理は、 Linuxがopen sourceであったからこそできた。 KernelにICE用の機能拡張コードを入れたりなど。 9. その他 ptraceはUNIXの頃からの古いAPI。 そろそろ新しい機能が必要と考えられる。 10. 質疑応答 1) SMP対応は? ICEは2個に見える。 しかしユーザにそうみえたら問題。一個にみえてほしい。 どっちでとまるかわからないので、そうゆう時の対応が必要。 今一番ホットな話題である。 2) ptraceのinterfaceについて。 /procあるのに、ptraceあるのおかしいとか考えられる。 CELFのWikiにptraceの問題点とかリストであげてほしい。