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

按照博客http://blog.csdn.net/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

祝各位好运！