[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: 64-bit Qemu and remote GDB to Kernel Error
From: |
Matt Davis |
Subject: |
[Qemu-devel] Re: 64-bit Qemu and remote GDB to Kernel Error |
Date: |
Tue, 5 Oct 2010 08:32:44 +1100 |
On Mon, Oct 4, 2010 at 8:00 PM, Jan Kiszka <address@hidden> 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:
>> address@hidden> 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
>