freebsd libcソースを-gオプションでコンパイルしたので、libc関数にステップインできます。
しかし、システムコールコードに足を踏み入れるのに問題があります。freebsdカーネルのソースコードを-gでコンパイルしました。ブレークポイントを設定すると、gdbは.Sファイルのブレークポイントについて通知します。ブレークポイントに到達すると、gdbはsyscallソースコードにステップインできなくなります。
また、私は試しました：gdb $ catch syscall open
しかし、これも機能していません。
何か提案してもらえますか？
ありがとう。
あなたは、UNIX システムがどのように機能するかについて根本的に理解していないようです。
考えてみてください。たとえば、システム コールを実装するカーネル関数にステップ インできたとしますsys_open。これsys_openで、デバッガーでのカーネル ソースが表示されます。問題は、その時点でカーネルが実行されているか、それとも停止しているかです。デバッガーでのようなことをしたいので、カーネルが停止しnextていると仮定しましょう。
では、nキーを押すとどうなりますか?
通常、カーネルはキーボードによって発生した割り込みに反応し、押されたキーを特定し、そのキーを適切なプロセス (read(2)キーボードを制御する端末からブロックされているプロセス) に送信します。
ただし、カーネルは停止しているため、キーを押す必要はありません。
結論: 同じマシンで実行されているデバッガーを介してカーネルをデバッグすることは不可能です。
実際、カーネルをデバッグするときは、通常、別のマシンでデバッガーを実行して実行します (これをリモート デバッグと呼びます)。
本当にカーネルにステップインしたい場合、それを行う最も簡単な方法はUMLを使用することです。
UML で遊んで、ユーザー空間/カーネル インターフェイスがどのように機能し、相互作用するかを理解したら、 を試すことができkgdbますが、セットアップは通常もう少し複雑です。このために別のマシンを実際に用意する必要はありません。VMWare、VirtualPC、または VirtualBox を使用できます。
Employed Russianがすでに述べたように、userlandにあるgdbは、カーネルで実行されているものを検査できません。
ただし、カーネル自体にデバッガーを実装することを妨げるものは何もありません。このような場合、ブレークポイントを設定し、ローカルデバッグセッション（コンソール）からカーネルコードを段階的に実行することができます。FreeBSDでは、そのようなデバッガーはddbとして利用できます。
いくつかの制限は、gdbセッションとddbセッションの間に接続がないことであり、FreeBSD / ddbのカーネルコードでソースレベルのデバッグ（-g）を使用できるかどうかはわかりません。
ユーザーランドからカーネルを「デバッグ」するための代替のはるかに邪魔にならない方法は、dtraceを使用することです。