linux - Depuración de bibliotecas compartidas con gdbserver

shared-libraries (4)

Buen día,

Si la variable ''debug-file-directory'' en GDB está configurada incorrectamente, los mensajes de error informados contienen: advertencia: no se puede encontrar la función del punto de enlace del enlazador dinámico.

El sistema de archivos raíz del destino se encuentra en mi PC host en / opt / arm-linux-gnueabihf-rootfs

Los siguientes dos comandos me ayudaron a obtener la depuración remota trabajando a través de gdbserver usando GDB (v7.11.1):

set debug-file-directory /opt/arm-linux-gnueabihf-rootfs/usr/lib/debug set sysroot /opt/arm-linux-gnueabihf-rootfs

Me he dado cuenta de que si ''sysroot'' tiene una barra inclinada en la ruta, entonces GDB no puede usarla. Verás esto (resultado incorrecto) luego de conectarte al objetivo remoto:

Reading /lib/ld-linux-armhf.so.3 from remote target...

Reading symbols from /opt/arm-linux-gnueabihf-rootfs/lib/ld-linux- armhf.so.3...(no debugging symbols found)...done

en lugar de la salida correcta:

Reading symbols from /opt/arm-linux-gnueabihf-rootfs/lib/ld-linux- armhf.so.3... Reading symbols from /opt/arm-linux-gnueabihf-rootfs/usr/lib/debug/ lib/arm-linux-gnueabihf/ld-2.23.so...done.

Saludos, Frikkie Thirion

Estoy usando gdbserver en Target y CodeSourcery IDE. Mi hardware es un gumstix con un omap3530.

Puedo acceder al código en mi aplicación principal, pero si intento ingresar a una función en una biblioteca compartida, obtengo una dirección de memoria y finaliza un depurador.

Esta es mi biblioteca que se compila y se copia a la carpeta / lib en el sistema de destino. (Tiene símbolos de depuración) He intentado usar el archivo .gbdinit para establecer solib-absolute-prefix / lib

Aquí están las advertencias del rastreo gdb:

903,056 13-gdb-set sysroot-on-target /lib 903,065 13^done 903,065 (gdb) 903,065 14-target-select remote 192.168.1.101:2345 903,114 =thread-group-started,id="i1",pid="42000" 903,114 =thread-created,id="1",group-id="i1" 903,115 15-list-thread-groups --available 903,120 16-list-thread-groups 903,128 &"warning: Unable to find dynamic linker breakpoint function./nGDB will be unable to debug shared library initializers/nand track explicitly loaded dynamic code." 903,128 &"/n"

Lo que lleva a

903,395 &"Error while mapping shared library sections:/n" 903,397 &"/lib/libCoreLib.so: Invalid argument./n" 903,399 =library-loaded,id="/lib/libCoreLib.so",target-name="/lib/libCoreLib.so",hostname="/lib/libCoreLib.so",low-address="0x0",high-address="0x0",symbols-loaded="0",thread-group="i1"

Problema similar se encontró durante la depuración. La depuración estaba colgando. La configuración es la siguiente

Anfitrión : Ubuntu 12.04LTS

IDE : Eclipse Kepler

Objetivo : Beaglebone Black / ARM A8

Sistema operativo : Angstrom

Solución

Actualizar bibliotecas e incluye

Seleccionar propiedades para el proyecto en Eclipse

C / C ++ General> Rutas y símbolos> (incluye TAB) GNU C> Agregar> Sistemas de archivos> /> usr Cambie de / usr / lib / gcc / i686-linux-gnu / 4/6 / include a / usr / arm- linux-gnueabi / include
C / C ++ General> Rutas y símbolos> (Incluir TAB) GNU C ++> Agregar>
Sistemas de archivos> /> usr /usr/arm-linux-gnueabi/include/c++/4.6.3/arm-linux-gnueabi
C / C ++ General> Rutas y símbolos> (TABLA Pathways de biblioteca)> Agregar> Sistemas de archivos> /> usr / usr / arm-linux-gnueabi / lib

Puede depurar con la biblioteca instalada en su host, siempre que la máquina de depuración sea también la máquina de desarrollo. En ese caso, use set sysroot en lugar de establecer sysroot-on-target. Por ejemplo :

set sysroot /home/username/.../rootfs/

donde /home/username/.../rootfs/ contiene una copia de su sistema de archivos de destino

Creo que también deberías especificar / lugar de /lib

Objetivo con símbolos de depuración

Este es el método más simple para trabajar, y es especialmente útil cuando se está desarrollando una biblioteca compartida en particular.

Primero copie el ejecutable de prueba y la biblioteca compartida al destino con información de depuración:

verifique con readelf ----debug-dump=decodedline libmyib.so : ¿Cómo puedo saber si una biblioteca fue compilada con -g?
Recomiendo usar un servidor NFS en el host, para que la salida compilada se cargue automáticamente después de la compilación

Luego en el objetivo:

gdbserver --multi :1234 ./executable_name

Anfitrión:

arm-linux-gnueabihf-gdb -q -nh / -ex "target extended-remote target-hostname-or-ip:1234" / -ex "file ./executable_name" / -ex ''tb main'' / -ex ''c'' / -ex ''set solib-search-path .''

sharedlibrary libmylib.so también funciona.

El problema que tuve fue que gdbserver detiene en el cargador dinámico, antes que en main , y las bibliotecas dinámicas aún no se han cargado en ese punto, por lo que GDB aún no sabe dónde irán los símbolos en la memoria.

GDB parece tener algunos mecanismos para cargar automáticamente los símbolos de la biblioteca compartida, y si compilo para el host y ejecuto gdbserver localmente, no es necesario ejecutar en main . Pero en el objetivo ARM, eso es lo más confiable que se puede hacer.

Target gdbserver 7.12-6, host arm-linux-gnueabihf-gdb 7.6.1 desde Linaro.

Bibliotecas de destino sin símbolos de depuración

Es común eliminar las bibliotecas de destino antes de la implementación en los objetivos integrados, ya que la información de depuración las hace mucho más grandes.

Por ejemplo, Buildroot lo hace de forma predeterminada, pero puede deshabilitarlo con BR2_STRIP_none=y .

Puede identificar este escenario ejecutando:

info shared

Que muestra algo así como:

From To Syms Read Shared Object Library 0x00007ffff7df7f90 0x00007ffff7dfcdd7 Yes (*) target:/lib/ld64-uClibc.so.0 0x00007ffff7b3a9b0 0x00007ffff7bbe05d Yes (*) target:/lib/libc.so.0 (*): Shared library is missing debugging information.

entonces hay asteriscos ( * ) para ambas bibliotecas que dicen que falta información de depuración.

Si ese es el caso, entonces debe decirle a GDB que use las bibliotecas compartidas en el host antes de que se eliminen.

Buildroot, por ejemplo, nos lo facilita, ya que mantiene el directorio provisional que contiene las bibliotecas compartidas antes de que fueran eliminadas y en las mismas rutas relativas que en el destino:

set sysroot buildroot/output/staging/

Cuando se establece esta opción, gdb busca inmediatamente las bibliotecas en el host en lugar del destino, y encuentra /lib/libc.so.0 en la ruta buildroot/output/staging/ + /lib/libc.so.0 :

Reading symbols from buildroot/output/staging/lib/ld64-uClibc.so.0...done. Reading symbols from buildroot/output/staging/lib/libc.so.0...done.

TODO: no creo que pueda establecer más de una sysroot , por lo que todas sus bibliotecas compartidas deben colocarse en sus rutas relativas correctas como en la imagen de destino.

Si comprueba el mal sysroot predeterminado, verá:

show sysroot

dar:

target:

lo que significa que gdb busca bibliotecas compartidas en la raíz de destino / por defecto.