2011-02-04 9 views
13

Tengo un problema con la depuración remota.La depuración cruzada remota gdb falla con "Remoto 'g' la respuesta del paquete es demasiado larga"

Host: ordenador portátil Intel i5 con Ubuntu 10.10 x86 Objetivo: Freescale iMX35 (iMX35 PDK) del brazo 11 Entorno de desarrollo: Qt Creator 2.1RC y bibliotecas Qt4.7.1. compilador brazo en ruta: /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin

brazo-ninguno-linux-gnueabi- gcc-4.1.2 arm-none-linux-gnueabi-objdump brazo-ninguno-linux-gnueabi-addr2line brazo-ninguno-linux-gnueabi-gccbug
brazo-ninguno-linux-gnueabi-ranlib brazo-ninguno-linux- gnueabi-ar
brazo-ninguno-linux-gnueabi-gcov brazo-ninguno-linux-gnueabi-readelf brazo-ninguno-linux-gnueabi -como
brazo-ninguno-linux-gnueabi a ejecutar brazo-ninguno-linux- gnueabi-C++
brazo-none-linux-gnueabi-size brazo-none-linux-gnueabi-C++ filt
brazo-ninguno-linux-gnueabi-gprof brazo-ninguno-linux-gnueabi-strings brazo-ninguno-linux-gnueabi-cpp brazo-ninguno-linux-gnueabi-ld
brazo-ninguno-linux-gnueabi-tira brazo -none-linux-gnueabi-g ++
brazo-ninguno-linux-gnueabi-nm brazo-ninguno-linux-gnueabi-gcc
brazo-ninguno-linux-gnueabi-objcopy

El objetivo es depurar un proyecto creado con Qt. Así que simplemente creé un Qt Quick Project -> Qt Quick Application que crea una aplicación Hello World simple (C++/Qml) Lo compilo cruzado (en depuración o versión) y funciona bien en el destino. Así que estoy bastante seguro de que la compilación cruzada no está relacionada con el problema que te mostraré.

He descargado GDB 7.2 y realiza la siguiente operación:

$ export PATH =/opt/Freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/brazo-ninguno -linux-gnueabi/bin: $ PATH
$ cd /home/elux/iMX35/gdb-7.2/
$ ./configure --target = brazo-no-linux-i686 gnueabi --build =
$ hacen
$ sudo make install

$ export CC = arm-none-linux-gnueabi-gcc
LD $ export = brazo-ninguno-linux-gnueabi-ld
$ cd GDB/gdbserver/
$ ./configure --build = i386 --host = brazo-ninguno-linux-gnueabi --target = brazo -ninguna-linux- gnueabi
$ hacen

$ sudo cp gdbserver/home/ELUX/MX35/ltib/rootfs/usr/bin/(copiar gdbserver para apuntar)

Luego, en el objetivo:

$ gdbserver 10.10.10.1: 4000 Prueba
Prueba de proceso creada; pid = 2194
escucha en el puerto 4000

El objetivo:

$ prueba del brazo-no-Linux-gnueabi-GDB (Test es cruzada compilado Qt Creator en modo de depuración) gDB de GNU (gDB) 7,2
copyright (C) 2010 Free software Foundation, Inc.
licencia GPLv3 +: GNU GPL versión 3 o posterior http://gnu.org/licenses/gpl.html
Este es software libre: usted es libre de cambiar y redistribuirlo.
NO HAY GARANTÍA, en la medida permitida por la ley. Escriba "Mostrar copia"
y "mostrar garantía" para obtener más información.
Este GDB se configuró como "--host = i686 --target = arm-none-linux-gnueabi".
Para obtener instrucciones a conocer un fallo, por favor ver:
http://www.gnu.org/software/gdb/bugs/ ...
símbolos de lectura de /home/elux/iMX35/ltib/rpm/BUILD/qt-everywhere-opensource-src-4.7.1/plataforma/Ensayos build-arm/Test ... hecho.
(GDB) de destino remoto 10.10.10.2:4000
La depuración remota utilizando la advertencia 10.10.10.2:4000
: No se puede analizar XML Descripción objetivo; El soporte XML se deshabilitó en el momento de la compilación
advertencia: no se puede encontrar la función del punto de enlace del enlazador dinámico.
BGF no será capaz de depurar compartidos inicializadores biblioteca
y realizar un seguimiento de código dinámico cargado de forma explícita.
0x400007e0 in ??()
(GDB)

y

(GDB) establecer solib-absoluta-prefix/home/ELUX/iMX35/ltib/rootfs/
símbolos de lectura desde/home/ELUX/iMX35/ltib/rootfs/lib/ld-linux.so.3 ... hecho.
Símbolos cargados para /home/elux/iMX35/ltib/rootfs/lib/ld-linux.so.3

pero

(GDB) arquitectura establecer ARMv5TE
Se supone que la arquitectura objetivo para ser ARMv5TE
respuesta paquete 'g' a distancia es demasiado largo: 00000000a7ee8ebe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b0ed8ebe00000000e007004010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000

(BGF) b principal
respuesta 'g' de paquetes a distancia es demasiado largo: 00000000a7ee8ebe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b0ed8ebe00000000e007004010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

¿Tienes alguna idea de lo que este problema está relacionado con? ¿Cómo puedo resolverlo?

Respuesta

7

Tuve el mismo problema al intentar depurar un ARM de Freescale en una máquina i5 que ejecuta Ubuntu 11.10 de 64 bits.

La solución que funcionó para mí fue especificar el --with-expat cuando se configura gdb. También tuve que instalar el paquete libexpat1-dev.

Explanation here

+0

Esta es la respuesta correcta. – BHS

13

Como me encontré con esto recientemente en Ubuntu 12.04 (x86_64) y lo resolvió de una manera diferente, que pensé en comento. El truco en este caso es que Ubuntu parece tener gdb con libexpat habilitado. Algunos pequeños ajustes más tarde y esta resuelto para mí:

conjunto de arquitectura i386: x86-64: Intel

Así que parece que esto puede resultar cuando hay un desajuste de arquitecturas.

+2

No sé sobre el OP, pero eso solucionó mi problema. Gracias un montón. –

+2

Si el problema persiste después de configurar la arquitectura, podría tratarse de un problema de cambio de tamaño de registro: http://stackoverflow.com/a/34304137/151464 –

9

Pude usar gdb-multiarch en su lugar y resolví mi problema.

Cuestiones relacionadas