无法单步进入系统调用源代码
我已经使用 -g 选项编译了我的 freebsd libc 源代码，这样我现在就可以进入 libc 函数了。
但我在进入系统调用代码时遇到问题。我已经用-g编译了freebsd内核源代码。设置断点时，gdb 会通知 .S 文件上的断点。当遇到断点时，gdb 无法单步执行系统调用源代码。
另外，我尝试过： gdb$catch syscall open
但这也不起作用。
你能建议一下吗？
谢谢。
I have compiled my freebsd libc source with -g option, so that now I can step in into libc functions.
But I am having trouble stepping into system calls code. I have compiled the freebsd kernel source code with -g. On setting the breakpoint, gdb informs about breakpoint on .S files. On hitting the breakpoint, gdb is unable to step into the syscall source code.
Also, I have tried: gdb$catch syscall open
but this is also not working.
Can you please suggest something?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您似乎对 UNIX 系统的工作原理缺乏了解。
想一想。假设您能够单步执行实现系统调用的内核函数，例如
sys_open。现在您正在调试器中查看sys_open的内核源代码。问题是：内核此时是否正在运行，或者是否已停止。由于您需要在调试器中执行类似next的操作，因此我们假设内核已停止。现在您按下
n键，会发生什么？通常，内核会对键盘引发的中断做出反应，找出按下了哪个键，并将该键发送到正确的进程（在 read(2) 中被阻止的进程） 来自控制键盘的终端）。
但是您的内核已停止，因此您无法按任何键。
结论：通过在同一台机器上运行的调试器调试内核是不可能的。
事实上，当人们调试内核时，他们通常是通过在另一台机器上运行调试器来完成的（这称为远程调试）。
如果您确实想进入内核，最简单的方法是使用 UML。
在使用 UML 并了解用户空间/内核接口如何工作和交互之后，您可以尝试
kgdb，尽管设置通常有点复杂。实际上，您不必为此拥有单独的计算机，您可以使用 VMWare 或 VirtualPC 或 VirtualBox。You appear to have fundamental lack of understanding of how UNIX systems work.
Think about it. Suppose you were able to step into the kernel function that implements a system call, say
sys_open. So now you are looking at the kernel source forsys_openin the debugger. The question is: is the kernel running at that point, or is it stopped. Since you will want to do something likenextin the debugger, let's assume the kernel is stopped.So now you press the
nkey, and what happens?Normally, the kernel will react to an interrupt raised by the keyboard, figure out which key was pressed, and send that key to the right process (the one that is blocked in
read(2)from the terminal that has control of the keyboard).But your kernel is stopped, so no key press for you.
Conclusion: debugging the kernel via debugger that is running on that same machine is impossible.
In fact, when people debug the kernel, they usually do it by running debugger on another machine (this is called remote debugging).
If you really want to step into kernel, the easiest way to do that is with UML.
After you've played with UML and understand how the userspace/kernel interface works and interacts, you can try
kgdb, though the setup is usually a bit more complicated. You don't actually have to have a separate machine for this, you could use VMWare or VirtualPC, or VirtualBox.正如 Employed Russian 已经指出的那样，位于用户态的 gdb 无法检查内核中运行的任何内容。
然而，没有什么可以阻止在内核本身中实现调试器。在这种情况下，可以设置断点并从本地调试会话（控制台）逐步运行内核代码。对于 FreeBSD，这样的调试器可以作为 ddb。
一些限制是 gdb 和 ddb 会话之间缺乏连接，并且我不确定源代码级调试 (-g) 是否可用于 FreeBSD/ddb 下的内核代码。
另一种从用户态“调试”内核的侵入性较小的方法是使用 dtrace。
As Employed Russian already stated, gdb being in userland cannot inspect anything running in the kernel.
However, nothing prevents to implement a debugger in the kernel itself. In such case, it is possible to set breakpoints and run kernel code step by step from a local debugging session (console). With FreeBSD, such a debugger is available as ddb.
Some limitations would be the lack of connection between your gdb and ddb sessions and I'm unsure source level debugging (-g) is available for kernel code under FreeBSD/ddb.
An alternate and much less intrusive way to 'debug' the kernel from userland would be to use dtrace.