在 Windows 主机上调试 VMWare 中的 Linux 内核
我正在开发我的第一个内核模块，所以我对此有点陌生......
我的模块偶尔会产生恐慌，我无法使用 printk 深入了解它。据我所知，我的调试选项是：
1.) 查找生成的 OOPS 消息并使用 ksymoops
或
2.) 尝试使用 kgdb 进行远程调试
我正在 Windows 主机上工作并在 VMWare 中运行 Ubuntu，因此事情变得复杂一点。我想先尝试 OOPS 消息，但我不知道如何捕获它。发生这种情况时我是否需要运行串行控制台？如果是这样，我该如何在 Windows 主机上做到这一点？我需要两个虚拟机吗？
就像我说的，我对此（以及一般的 Linux）有点陌生，所以我真的可以使用一些指导。谢谢！
I'm working on my first ever kernel module so I'm a bit new at this...
My module is occasionally producing a panic and I cannot get to the bottom of it using printk. As far as I can tell my options for debugging are:
1.) Find the generated OOPS message and use ksymoops
or
2.) Try at remote debug using kgdb
I'm working on a windows host and running Ubuntu in VMWare so that complicates things a bit. I'd like to try the OOPS message first but I don't know how to capture it. Do I need to be running a serial console when it happens? If so, how can I do that with Windows host? Do I need two VM's?
Like I said, I'm a bit new to this (and Linux in general) so I could really use some guidance. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不确定这是否对您在 Winblowz 上有帮助，但如果您可以将虚拟机移动到 Linux 机器上：
使用 Workstation 6.0 调试 Linux 内核
我认为这可能也适用于其他最新的 VMware 产品。
由于它也适用于 Mac OSX，我怀疑它也适用于 Winblowz：
调试 linux 内核（在 vmware 内）来自 Mac OSX
正如此线程所建议的，您还可以从同一计算机上运行的第二个 Linux VM 远程调试一个 Linux VM。
I'm not sure if this will help you on Winblowz, but if you can move your VM to a linux box:
Debugging Linux kernels with Workstation 6.0
I think this probably works on other recent VMware products as well.
Since it works on Mac OSX as well I suspect it would work on Winblowz also:
Debugging linux kernel (inside vmware) from Mac OSX
As this thread suggests, you might also remotely debug one linux VM from a second linux VM running on the same machine.
看看这是否有帮助。我不使用 Windows 或 VMWare http://communities.vmware。 com/thread/236251;jsessionid=A4A69CC15C7B951C576EF254604655D8?tstart=0
See if this helps. I don't use Windows or VMWare http://communities.vmware.com/thread/236251;jsessionid=A4A69CC15C7B951C576EF254604655D8?tstart=0
不久前我成功地使用了“alinrus”所指的技术。他提到的部分详细解释在：
http://stackframe.blogspot.com/2007/04/ debug-linux-kernels-with.html
我实际上直接从 Windows 主机使用它。因此，在设置虚拟机之后（主要是启用远程调试和下载内核（vmlinux 文件，不是 gdb 无法解释的 vmlinuz 文件）），您需要执行以下操作
这就是调试静态链接到内核的代码所需的。您可以尝试静态链接您的模块，上面的内容就足够了。为动态链接模块设置调试需要额外的步骤来通知 gdb 使用模块文件，以及如何解释文件的部分。
3a.加载模块后（在导致模块崩溃之前:)），在 .ko 文件上运行下面的脚本。
3b.将生成的“add-symbol-file mymodule.ko 0xe8884000 ...”行粘贴到 gdb 中。然后，gdb 将加载您的模块，只要它可以在当前目录或您指定的路径中找到它。
脚本来自 http://anomit.com/ 2009/11/04/kernel-module-debugging-a-simple-technique/
#!/bin/sh # # gdbline module image # # Outputs an add-symbol-file line suitable for pasting into gdb to examine # a loaded module. # cd /sys/module/$1/sections PROG=${1}.ko echo -n add-symbol-file ${PROG} `/bin/cat .text` #echo -n add-symbol-file $2 `/bin/cat .text` #Take second argument to be gdb name of program/object file for section in .[a-z]* *; do if [ $section != ".text" ]; then echo " \\" echo -n " -s" $section `/bin/cat $section` fi done echo您可能还想做更多的事情。要进行实际的源代码级调试，您需要获取所有内核和模块源代码，以便 gdb 可以找到它。一旦你做到了这一点，你可以使用一些技巧来编译你的模块而无需优化。
您可能还想查看 Workstation 7.0 关于重播调试的技术说明，其中包含有关调试内核模块的信息。 VMware 了解他们的东西。
http://www.vmware.com/pdf/ws7_replay_linux_technote.pdf
A while ago I successfully used the technique "alinrus" refers to. The part he mentioned is explained in detail at:
http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html
I actually used it directly from a Windows host. So after setting up the VM (mainly enabling remote debugging and downloading the kernel (the vmlinux file, not the vmlinuz file which cannot be interpreted by gdb)), you would need to do the following:
That is what you need to debug code which is statically linked into the kernel. You could try statically linking your module and the above would be sufficient. Setting up debugging for a dynamically-linked module requires an additional step to inform to gdb to use your module file as well, and how to interpret the file's sections.
3a. Run the script below on your .ko file, after loading the module (and before crashing it :) ).
3b. Paste the resulting "add-symbol-file mymodule.ko 0xe8884000 ..." lines into gdb. gdb will then load your module, as long as it can find it in the current directory or path you specify.
Script is from http://anomit.com/2009/11/04/kernel-module-debugging-a-simple-technique/
#!/bin/sh # # gdbline module image # # Outputs an add-symbol-file line suitable for pasting into gdb to examine # a loaded module. # cd /sys/module/$1/sections PROG=${1}.ko echo -n add-symbol-file ${PROG} `/bin/cat .text` #echo -n add-symbol-file $2 `/bin/cat .text` #Take second argument to be gdb name of program/object file for section in .[a-z]* *; do if [ $section != ".text" ]; then echo " \\" echo -n " -s" $section `/bin/cat $section` fi done echoThere are more things you may want to do. To do actual source-level debugging you'll want to suck down all the kernel and module source code so that gdb can find it. And there are some tricks you can use to compile your module without optimization once you get this far.
You may also want to look at Workstation 7.0's tech note on replay debugging, which contains information on debugging kernel modules. VMware knows their stuff.
http://www.vmware.com/pdf/ws7_replay_linux_technote.pdf