Qemu 调试内核出错 Remote 'g' packet reply is too long:

最新推荐文章于 2024-04-04 23:42:41 发布

SunnyBeiKe

最新推荐文章于 2024-04-04 23:42:41 发布

阅读量4.7k

点赞数 1

CC 4.0 BY-SA版权

分类专栏： Linux内核分析

本文链接：https://blog.youkuaiyun.com/SunnyBeiKe/article/details/40650623

Linux内核分析专栏收录该内容

9 篇文章

订阅专栏

在使用Qemu调试内核时遇到'Remote 'g' packet reply is too long'的错误。尝试了不同版本的Qemu和gdb未果。文章提到-QEMU的'-S'参数可能导致问题，但不采用此方法。最终通过修改gdb源码解决了问题，主要修改了处理buf_len超过限制时的代码。Qemu版本为2.1.2，gdb为7.8，内核为2.6.31.4。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

按照博客http://blog.youkuaiyun.com/sunnybeike/article/details/6648815Qemu 调试内核，

qemu的启动方式如下，

qemu-system-x86_64 -kernel bzImage -hda linux-0.2.img -append "root=/dev/hda" -S

在弹出的qemu中，按住Ctrl+Alt+2，进入Qemu控制端，然后输入 gdbserver

然后，另起一个端口，输入

gdb vmlinux

出现如下错误：

Remote 'g' packet reply is too long: 28636081ffffffff6cca69010000000000fc090000000000685f5481fffffffff9774a81ffffffff36636081ffffffffb85f5481ffffffffa05f5481ffffffff00800001000000000000000000000000985f5481ffffffffd03101000000000000000000000000000000000000000000000000000000000000000000000000006a925d81ffffffff4600000010000000180000001800000018000000180000001800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000

(gdb)

尝试了不同版本的Qemu和gdb，但是都没有解决问题，实际上是gdb出现问题了。

这篇文章（http://www.yonch.com/tech/84-debugging-the-linux-kernel-with-qemu-and-eclipse）解释了原因，

“Note that other tutorials also add a "-S" parameter so QEMU starts the kernel stopped, however this is ommitted deliberately. The "-S" parameter would allow gdb to set an initial breakpoint anywhere in the kernel before kernel execution begins. Unfortunately, a change made to the gdbserver in QEMU, to support debugging 32- and 16-bit guest code in an x86_64 session breaks the -S functionality. The symptoms are that gdb prints out "Remote 'g' packet reply is too long:", and fails to interact successfully with QEMU. The suggested fix is to run the QEMU until it is in 64-bit code (i.e. after the boot loader has finished and the kernel started) before connecting from gdb (omitting the -S parameter). To debug a running kernel, this is sufficient; it is the method we will take.”

但是它的解决方案我没有尝试，

我尝试了这篇文章（http://augustl.com/blog/2014/gdb_progress/）的解决方案，即在gdb开始后，指定体系结构，按照如下方式：

但是失败了。想来，在启动qemu的时候就是用的qemu-system-x86_64，已经指定了要模拟的CPU，再在GDB中指定，是不是多次依据，看来这个也不是解决方案。。

真正的解决方案参考http://blog.sina.com.cn/s/blog_8709e3120101gst1.html，需要修改gdb源码，修改方式如下。主要就是修改buf_len > 2*rsa->sizeof_g_packet时，gdb的处理方式。注意，我用的是7.8内核，所以修改的源码和这篇博客（http://blog.sina.com.cn/s/blog_8709e3120101gst1.html）不太一样，它用的7.5内核。所以，请留意。不过，其实只是结构体变量引用方式的不同。

if (buf_len > 2 * rsa->sizeof_g_packet) {

rsa->sizeof_g_packet = buf_len ;

for (i = 0; i < gdbarch_num_regs (gdbarch); i++) {

if (rsa->regs->pnum == -1)

continue;

if (rsa->regs->offset >= rsa->sizeof_g_packet)

rsa->regs->in_g_packet = 0;

else

rsa->regs->in_g_packet = 1;

}

ps：我的qemu用的是2.1.2,gdb用的是7.8,linux是2.6.31.4

祝各位好运！