Bug 612578

Summary:	GDB Server behaves weirdly
Product:	[Fedora] Fedora	Reporter:	Tobias Mueller <fedora-bugs>
Component:	qemu	Assignee:	Fedora Virtualization Maintainers <virt-maint>
Status:	CLOSED DEFERRED	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	23	CC:	amit.shah, a.spam.filter, berrange, crobinso, dwmw2, ehabkost, itamar, jaswinder, jforbes, knoel, ondrejj, pbonzini, scottt.tw, tburke, virt-maint, zorro6467
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-14 14:20:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tobias Mueller 2010-07-08 14:44:32 UTC

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:

Comment 1 Tobias Mueller 2010-07-08 16:10:57 UTC

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.

Comment 2 Tobias Mueller 2010-07-09 00:57:50 UTC

It's better if the kernel is booted. It then works without any problems.

Comment 3 Bug Zapper 2011-06-01 14:25:36 UTC

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

Comment 4 Tobias Mueller 2011-06-25 16:32:21 UTC

Still the very same issue with F14.

Comment 5 Cole Robinson 2012-05-20 22:11:04 UTC

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.

Comment 6 Tobias Mueller 2012-05-20 22:37:55 UTC

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.

Comment 7 Tobias Mueller 2012-07-07 13:23:41 UTC

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)

Comment 8 FerrisZorro 2013-07-12 12:42:50 UTC

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?

Comment 9 Paolo Bonzini 2013-11-27 12:40:26 UTC

No, but I have a workaround.  Before connecting to gdb with "target remote", use "set arch i386:x86-64".

Comment 10 Jan Kurik 2015-07-15 15:19:16 UTC

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

Comment 11 Cole Robinson 2015-10-14 14:20:58 UTC

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.