Fwd: Remote 'g' packet reply is too long

[yajin]

---------- Forwarded message ----------
From: yajin
Date: Mon, 20 Apr 2009 04:47:35 -0700 (PDT)
Subject: Remote 'g' packet reply is too long
To: loongson-dev <loongs...@googlegroups.com>
Hi all,
I build a cross gdb to remote debug qemu. I using the following
compile flag:
--target=mipsel-gdium-linux-gnu
When I use it to remote debug qemu, there is an error:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
[New Thread 1]
Remote 'g' packet reply is too long:
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040040000000000000000000000000000000000000000000000000000000000000000000000000000000c0bfffffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001050000000000000000000000000000
It seems gdb sends too long message to the 'g' command. There is a
mismatch with the gdb and remote machine(qemu).
Any knows how to solve this issue? Maybe I need to dig into the gdb
source code to find the root cause......

[yajin zhou]

Hi all,

I find the root cause of this issue.Before we use remote gdb to debug program, we SHOULD load the elf file to gdb first, even if we do not want care the symbol information in the elf file. It will tell gdb the detailed information of ABI of current program, for MIPS has three types of different ABI. If we do not load the elf file, the gdb will use the default value, which may be not correct some times. We can use the 'maintenance print architecture' to see detailed information of current architecture gdb thinks.

Let's take my last issue as an example. The first time I do not load the elf file, the 'maintenance print architecture' command prints out the following information:

mips_dump_tdep: tdep->elf_flags = 0x0
mips_dump_tdep: ef_mips_32bitmode = 0
mips_dump_tdep: ef_mips_arch = 1
mips_dump_tdep: tdep->mips_abi = 2 (o32)
mips_dump_tdep: mips_mask_address_p() 0 (default 0)
mips_dump_tdep: MIPS_DEFAULT_FPU_TYPE = 0 (double)
mips_dump_tdep: MIPS_EABI = 0
mips_dump_tdep: MIPS_FPU_TYPE = 0 (double)

The second time I load the elf file using file command, the command prints out the following information:

mips_dump_tdep: tdep->elf_flags = 0x20000001
mips_dump_tdep: ef_mips_32bitmode = 0
mips_dump_tdep: ef_mips_arch = 3
mips_dump_tdep: tdep->mips_abi = 2 (o32)
mips_dump_tdep: mips_mask_address_p() 0 (default 0)
mips_dump_tdep: MIPS_DEFAULT_FPU_TYPE = 0 (double)
mips_dump_tdep: MIPS_EABI = 0
mips_dump_tdep: MIPS_FPU_TYPE = 0 (double)

Then I use target remote localhost:1234 to attach gdb to qemu and it works.

Some issue still exist, the breakpoints set by gdb have no effect in qemu for example, however. I think it's because of the mismatch of address bits between qemu and gdb, qemu uses 64bit address while gdb uses 32bit. I will dig into the qemu source code and solve this issue later. give me a minute please. :)

yajin

http://vm-kernel.org