Gdb remote cross debugging fails with “Remote ‘g’ packet reply is too long”

debugginggdbgdbserverqt-creatorqt4

I have a problem with remote debugging.

Host: laptop intel i5 with ubuntu 10.10 x86
Target: Freescale iMX35 (iMX35 PDK) arm 11
Development environment: Qt Creator 2.1RC and Qt4.7.1 libraries.
Arm compiler in path: /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin

arm-none-linux-gnueabi-gcc-4.1.2 arm-none-linux-gnueabi-objdump
arm-none-linux-gnueabi-addr2line arm-none-linux-gnueabi-gccbug
arm-none-linux-gnueabi-ranlib arm-none-linux-gnueabi-ar
arm-none-linux-gnueabi-gcov arm-none-linux-gnueabi-readelf
arm-none-linux-gnueabi-as
arm-none-linux-gnueabi-run arm-none-linux-gnueabi-c++
arm-none-linux-gnueabi-size arm-none-linux-gnueabi-c++filt
arm-none-linux-gnueabi-gprof arm-none-linux-gnueabi-strings
arm-none-linux-gnueabi-cpp arm-none-linux-gnueabi-ld
arm-none-linux-gnueabi-strip arm-none-linux-gnueabi-g++
arm-none-linux-gnueabi-nm arm-none-linux-gnueabi-gcc
arm-none-linux-gnueabi-objcopy

The goal is to debug a project created with Qt.
So I simply created a Qt Quick Project -> Qt Quick Application
which creates a simple Hello World application (C++/Qml)
I cross compile it (in debug or release) and it works fine
on the target. So I'm quite sure that cross compilation
is not related to the problem I'll show you.

I downloaded gdb 7.2 and performed the following operation:

$ export PATH=/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin:$PATH
$ cd /home/elux/iMX35/gdb-7.2/
$ ./configure –target=arm-none-linux-gnueabi –build=i686
$ make
$ sudo make install

$ export CC=arm-none-linux-gnueabi-gcc
$ export LD=arm-none-linux-gnueabi-ld
$ cd gdb/gdbserver/
$ ./configure –build=i386 –host=arm-none-linux-gnueabi –target=arm-none-linux-
gnueabi
$ make

$ sudo cp gdbserver /home/elux/MX35/ltib/rootfs/usr/bin/ (to copy gdbserver to target)

Then on the target:

$ gdbserver 10.10.10.1:4000 Test
Process Test created; pid = 2194
Listening on port 4000

On the target:

$ arm-none-linux-gnueabi-gdb Test (Test is cross-compiled it Qt Creator in debug mode)
GNU gdb (GDB) 7.2
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 "–host=i686 –target=arm-none-linux-gnueabi".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/
Reading symbols from /home/elux/iMX35/ltib/rpm/BUILD/qt-everywhere-opensource-src-4.7.1 /platform/Test-build-arm/Test…done.
(gdb) target remote 10.10.10.2:4000
Remote debugging using 10.10.10.2:4000
warning: Can not parse XML target description; XML support was disabled at compile time
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
0x400007e0 in ?? ()
(gdb)

and

(gdb) set solib-absolute-prefix /home/elux/iMX35/ltib/rootfs/
Reading symbols from /home/elux/iMX35/ltib/rootfs/lib/ld-linux.so.3…done.
Loaded symbols for /home/elux/iMX35/ltib/rootfs/lib/ld-linux.so.3

but

(gdb) set architecture armv5te
The target architecture is assumed to be armv5te
Remote 'g' packet reply is too long: 00000000a7ee8ebe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b0ed8ebe00000000e007004010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

(gdb) b main
Remote 'g' packet reply is too long: 00000000a7ee8ebe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b0ed8ebe00000000e007004010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Have you got any idea what this problem is related to? How can I resolve it?

Best Answer

I was able to use gdb-multiarch instead and resolved my issue.

Related Topic