Description of problem: I can't debug a Linux kernel with QEmu, because I get: Remote 'g' packet reply is too long: 502cc2...[..loads of hex..]... Version-Release number of selected component (if applicable): qemu from Fedora 12 but also from git How reproducible: Terminal 1: $ qemu-system-x86_64 -m 1G -smp 1 -hda /opt/ubuntu.img -snapshot -kernel ~/git/linux-2.6/arch/x86_64/boot/bzImage -append 'root=/dev/sda1' -s -S Terminal 2: $ gdb ~/git/linux-2.6/vmlinux GNU gdb (GDB) Fedora (7.1-28.fc13) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/muelli/git/linux-2.6/vmlinux...done. (gdb) br start_kernel Breakpoint 1 at 0xffffffff81bab9bf: file init/main.c, line 544. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0x0000000000000000 in ?? () (gdb) c Continuing. Remote 'g' packet reply is too long: 502cc281ffffffffa825e201000000005e2cc281ffffffff00000000000000006c997881ffffffff002cc281ffffffff881fa081ffffffff701fa081ffffffff402cc281ffffffff402cc281ffffffff0000000000000000200000000000000000000000000000000020c881ffffffffa81fa081ffffffffa037010000000000b0b9ba81ffffffff0200000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000 (gdb) Steps to Reproduce: 1. $ qemu-system-x86_64 -m 1G -smp 1 -hda /opt/ubuntu.img -snapshot -kernel ~/git/linux-2.6/arch/x86_64/boot/bzImage -append 'root=/dev/sda1' -s -S 2. $ gdb ~/git/linux-2.6/vmlinux 3. br start_kernel; c Actual results: Expected results: I expected to be able to debug fine. Note that I don't whether this is a GDB or a QEmu issue. Additional info:
I've seen http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509479 and FWIW: $ gdb ~/git/linux-2.6/vmlinux GNU gdb (GDB) Fedora (7.1-28.fc13) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/muelli/git/linux-2.6/vmlinux...done. (gdb) (gdb) show architecture The target architecture is set automatically (currently i386:x86-64) (gdb) So the architecture seems to be correctly already. And setting it to i386:x86-64:intel as supposed in that bug report doesn't help it, either.
It's better if the kernel is booted. It then works without any problems.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still the very same issue with F14.
F14 is end-of-life now. Tobias, if you're still affected by this bug with newer qemu versions (fedora 16 or 17), please reopen this report and we can forward this upstream.
Yep, stil a problem: $ gdb /boot/vmlinuz-3.3.5-2.fc16.x86_64 GNU gdb (GDB) Fedora (7.3.50.20110722-13.fc16) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /boot/vmlinuz-3.3.5-2.fc16.x86_64...(no debugging symbols found)...done. (gdb) br start_kernel No symbol table is loaded. Use the "file" command. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (start_kernel) pending. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0x0000000000000000 in ?? () (gdb) c Continuing. ^CRemote 'g' packet reply is too long: 2cfec9800900000000000000000000002cfec98000000000389513000000000000000000000000001aa8260000000000a09da43d0088ffff789da43d0088ffff0100000000000000000000000000000000000000000000000100000000000000f468b6800000000000000000000000001aa8260000000000a0b19a81ffffffff80c30181ffffffff4602000010000000180000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000 Remote 'g' packet reply is too long: 2cfec9800900000000000000000000002cfec98000000000389513000000000000000000000000001aa8260000000000a09da43d0088ffff789da43d0088ffff0100000000000000000000000000000000000000000000000100000000000000f468b6800000000000000000000000001aa8260000000000a0b19a81ffffffff80c30181ffffffff4602000010000000180000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000 Remote 'g' packet reply is too long: 2cfec9800900000000000000000000002cfec98000000000389513000000000000000000000000001aa8260000000000a09da43d0088ffff789da43d0088ffff0100000000000000000000000000000000000000000000000100000000000000f468b6800000000000000000000000001aa8260000000000a0b19a81ffffffff80c30181ffffffff4602000010000000180000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000 (gdb) I read somewhere that the problem is, that the GDB server cannot tell the local GDB that the architecture has changed. And that, for some reason, x86_64 does exactly that, i.e. first running in 32bit mode and then the kernel switches to 64bit mode at some stage. And that was, were GDB breaks.
Still an issue with F17: (gdb) c Continuing. ^CRemote 'g' packet reply is too long: dc3ad3630300000000000000000000001a00000000000000dc3ad36303000000000000000000000027a826000000000070bda43d0088ffff50bda43d0088ffff0000000000000000000000000000000000000000000000000000000000000000a85fbb630000000027a8260000000000000000000000000000400d3d0088ffffaacb2c81ffffffff0202000010000000180000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000 Remote 'g' packet reply is too long: dc3ad3630300000000000000000000001a00000000000000dc3ad36303000000000000000000000027a826000000000070bda43d0088ffff50bda43d0088ffff0000000000000000000000000000000000000000000000000000000000000000a85fbb630000000027a8260000000000000000000000000000400d3d0088ffffaacb2c81ffffffff0202000010000000180000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000 Remote 'g' packet reply is too long: dc3ad3630300000000000000000000001a00000000000000dc3ad36303000000000000000000000027a826000000000070bda43d0088ffff50bda43d0088ffff0000000000000000000000000000000000000000000000000000000000000000a85fbb630000000027a8260000000000000000000000000000400d3d0088ffffaacb2c81ffffffff0202000010000000180000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000 (gdb)
The problem "Remote 'g' packet reply is too long:" also happens on Ubuntu12.04 (x86_64), when debugging linux kernel with gdb(7.6) and qemu-kvm-1.0. Can you solve it?
No, but I have a workaround. Before connecting to gdb with "target remote", use "set arch i386:x86-64".
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
There's been a few other bugs about this with a bit more info: https://bugzilla.redhat.com/show_bug.cgi?id=1097779 https://sourceware.org/bugzilla/show_bug.cgi?id=13984 I don't understand all the variables here, but that bugzilla.redhat.com bug suggests there _is_ something qemu can do to make the 'set arch' bit unnecessary. But the problem seems well known at this point and all references online to using qemu gdb stub suggest to use the 'set arch' command, so in practice it's not a big deal. Since this bug has lingered for such a long time and it isn't generating any results, I'm closing it. If anyone wants to follow up with qemu to investigate a permanent fix, I suggest jumping on the above gdb bug, or filing an upstream qemu bug about it.