[Qemu-devel] 64-bit Qemu and remote GDB to Kernel Error

[Qemu-devel] 64-bit Qemu and remote GDB to Kernel Error

[Matt Davis]

Hello,
I am trying to debug a 32-bit linux kernel with gdb and qemu.  My qemu
runs the 64-bit kernel as:
user@host> qemu -kernel vmlinuz -S -s  (not using kvm).  If I try with
kvm the breakpoint does not even seem to get tripped.

And then I fire up gdb on my 64-bit machine (the same one running
qemu).  And I set my "target remote :1234" and set a breakpoint.
Anyways, I seem to catch my breakpoint, but when it should be tripping
I get the following error :
Remote 'g' packet reply is too long: <data>

I have done similar stuff fine on a 32bit machine running both 32-bit
qemu and a 32-bit kernel.  I have also googled, and this seems to not
be uncommon (circa 2008).  But I have not seen anything recently
regarding this.  Should it be working now?  If not is there a better
solution?  I tried, on my 64bit machine, to run a 32-bit kernel in
qemu, but my breakpoints were still not tripping in gdb.  Yes, the
kernel did have debugging flags built in.  I also forced the gdb
architecture to use "set arch i386:x86-64" not much difference if I
recall.

The following thread had similar issues when trying to set a break in
64 bit land, but not mention of the error I reported above.  These
possibly cold be related:
http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00287.html

-Matt

[Qemu-devel] Re: 64-bit Qemu and remote GDB to Kernel Error

[Jan Kiszka]

Am 04.10.2010 04:47, Matt Davis wrote:
> Hello,
> I am trying to debug a 32-bit linux kernel with gdb and qemu.  My qemu
> runs the 64-bit kernel as:
> user@host> qemu -kernel vmlinuz -S -s  (not using kvm).  If I try with
> kvm the breakpoint does not even seem to get tripped.

Which qemu version is affected by this issue?

> 
> And then I fire up gdb on my 64-bit machine (the same one running
> qemu).  And I set my "target remote :1234" and set a breakpoint.
> Anyways, I seem to catch my breakpoint, but when it should be tripping
> I get the following error :
> Remote 'g' packet reply is too long: <data>
> 
> I have done similar stuff fine on a 32bit machine running both 32-bit
> qemu and a 32-bit kernel.  I have also googled, and this seems to not
> be uncommon (circa 2008).  But I have not seen anything recently
> regarding this.  Should it be working now?  If not is there a better
> solution?  I tried, on my 64bit machine, to run a 32-bit kernel in
> qemu, but my breakpoints were still not tripping in gdb.  Yes, the
> kernel did have debugging flags built in.  I also forced the gdb
> architecture to use "set arch i386:x86-64" not much difference if I
> recall.
> 
> The following thread had similar issues when trying to set a break in
> 64 bit land, but not mention of the error I reported above.  These
> possibly cold be related:
> http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00287.html

Please also see this thread
http://thread.gmane.org/gmane.comp.emulators.qemu/80327. Did you follow
the procedure I suggested? I cannot derive this from your description.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: 64-bit Qemu and remote GDB to Kernel Error

[Matt Davis]

On Mon, Oct 4, 2010 at 8:00 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Am 04.10.2010 04:47, Matt Davis wrote:
>> Hello,
>> I am trying to debug a 32-bit linux kernel with gdb and qemu.  My qemu
>> runs the 64-bit kernel as:
>> user@host> qemu -kernel vmlinuz -S -s  (not using kvm).  If I try with
>> kvm the breakpoint does not even seem to get tripped.
>
> Which qemu version is affected by this issue?

Jan,
The version of qemu I am running is:
QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c)
2003-2008 Fabrice Bellard

The version of gdb is: 7.2

-Matt




>> And then I fire up gdb on my 64-bit machine (the same one running
>> qemu).  And I set my "target remote :1234" and set a breakpoint.
>> Anyways, I seem to catch my breakpoint, but when it should be tripping
>> I get the following error :
>> Remote 'g' packet reply is too long: <data>
>>
>> I have done similar stuff fine on a 32bit machine running both 32-bit
>> qemu and a 32-bit kernel.  I have also googled, and this seems to not
>> be uncommon (circa 2008).  But I have not seen anything recently
>> regarding this.  Should it be working now?  If not is there a better
>> solution?  I tried, on my 64bit machine, to run a 32-bit kernel in
>> qemu, but my breakpoints were still not tripping in gdb.  Yes, the
>> kernel did have debugging flags built in.  I also forced the gdb
>> architecture to use "set arch i386:x86-64" not much difference if I
>> recall.
>>
>> The following thread had similar issues when trying to set a break in
>> 64 bit land, but not mention of the error I reported above.  These
>> possibly cold be related:
>> http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00287.html
>
> Please also see this thread
> http://thread.gmane.org/gmane.comp.emulators.qemu/80327. Did you follow
> the procedure I suggested? I cannot derive this from your description.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>

[Qemu-devel] Re: 64-bit Qemu and remote GDB to Kernel Error

[Jan Kiszka]

Am 04.10.2010 23:32, Matt Davis wrote:
> On Mon, Oct 4, 2010 at 8:00 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> Am 04.10.2010 04:47, Matt Davis wrote:
>>> Hello,
>>> I am trying to debug a 32-bit linux kernel with gdb and qemu.  My qemu
>>> runs the 64-bit kernel as:
>>> user@host> qemu -kernel vmlinuz -S -s  (not using kvm).  If I try with
>>> kvm the breakpoint does not even seem to get tripped.
>>
>> Which qemu version is affected by this issue?
> 
> Jan,
> The version of qemu I am running is:
> QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c)
> 2003-2008 Fabrice Bellard
> 
> The version of gdb is: 7.2
> 

OK, now I realize the reason of this effect: KVM uses software
breakpoints by default, i.e. it injects int3 into the guest code. If you
do this before the kernel was loaded, they will be overwritten by the
actual code later on. Use hardware breakpoints in case you want to trap
the guest early. Otherwise activate the breakpoints after the kernel was
loaded into RAM.

You don't have this limitation in emulation mode as, here, you can
modify the guest code transparently (effectively, all breakpoints are
hardware breakpoints then, and they are not limited in amount).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux