Débogage des bibliothèques partagées avec gdbserver

Je suis en utilisant gdbserver sur la cible et CodeSourcery IDE. Mon matériel est un gumstix avec un omap3530.

Je peux parcourir le code de mon application principale, mais si je tente de l'étape dans une fonction dans une bibliothèque partagée-je obtenir de l'adresse de mémoire et un débogueur s'arrête.

C'est ma bibliothèque qui est compilé et copié dans le répertoire /lib dossier sur le système cible.(il a les symboles de débogage), j'ai tenté d'utiliser l' .gbdinit fichier pour définir solib-absolue-prefix /lib

Ici sont les mises en garde de la gdb trace:

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"

Qui conduit à

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"
Voir si cet article vous aide à: fayewilliams.com/2013/01/31/...

OriginalL'auteur Seth | 2011-12-23

  1. 4

    Vous pouvez déboguer avec la bibliothèque installé sur votre ordinateur hôte, à condition que le débogage de la machine est également la machine de développement. Dans ce cas, l'utilisation de set sysroot au lieu de définir la sysroot-sur-cible. Par exemple :

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

    où /home/username/.../rootfs/ contient une copie de votre cible de système de fichiers

    Je pense que vous devez aussi spécifier / au lieu de /lib

    Mon hôte de débogage de la machine est une machine windows, donc je ne suis pas sûr où mon rootfs serait situé sur. merci

    OriginalL'auteur shodanex

  2. 1

    Cible avec des symboles de débogage

    C'est la méthode la plus simple pour obtenir de travail, et il est particulièrement utile lors du développement d'un particulier de la bibliothèque partagée.

    Copiez d'abord le test de l'exécutable et partagée de la bibliothèque de la cible avec les informations de débogage:

    Puis sur la cible:

    gdbserver --multi :1234 ./executable_name

    De l'hôte:

    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 fonctionne également.

    Le problème que j'avais était que gdbserver s'arrête à la chargeur dynamique, avant main, et les bibliothèques dynamiques ne sont pas encore chargés, à ce point, et ainsi de GDB ne sais pas où les symboles vont aller dans la mémoire encore.

    GDB semble avoir un certain nombre de mécanismes pour charger automatiquement partagée de la bibliothèque de symboles, et si je compile pour l'hôte, et d'exécuter gdbserver localement, en cours d'exécution pour main n'est pas nécessaire. Mais sur le BRAS de la cible, qui est le plus fiable chose à faire.

    Cible gdbserver 7.12-6, hôte arm-linux-gnueabihf-gdb 7.6.1 de Linaro.

    Cible bibliothèques sans les symboles de débogage

    Il est fréquent de bande cible bibliothèques avant le déploiement sur des cibles embarquées, depuis les informations de débogage rend façon plus.

    Par exemple, Buildroot n'est que par défaut, mais vous pouvez le désactiver avec BR2_STRIP_none=y.

    Vous pouvez identifier ce scénario en cours d'exécution:

    info shared

    Qui montre quelque chose comme:

    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.

    il y a donc des astérisques (*) pour les deux bibliothèques qui dit que les informations de débogage est manquant.

    Si c'est le cas, alors vous avez à dire GDB pour utiliser les bibliothèques partagées sur l'hôte avant ils ont été dépouillés.

    Buildroot pour exemple le rend facile pour nous, car il maintient la staging répertoire qui contient les bibliothèques partagées avant qu'ils ont été dépouillés et dans les mêmes chemins relatifs, comme dans la cible:

    set sysroot buildroot/output/staging/

    Lorsque cette option est définie, gdb immédiatement des recherches pour les bibliothèques à l'accueil au lieu de la cible, et trouve /lib/libc.so.0 au chemin 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: je ne pense pas que vous pouvez définir plus d'une sysroot, de sorte que tous vos bibliothèques partagées doivent être placés dans leur correcte des chemins relatifs, comme dans l'image cible.

    Si vous cochez la mauvaise défaut sysroot, vous verrez:

    show sysroot

    donner:

    target:

    ce qui signifie que gdb recherches pour les bibliothèques partagées sur la racine cible / par défaut.

    OriginalL'auteur Ciro Santilli 新疆改造中心996ICU六四事件

  3. 0

    Même problème a été rencontré lors du débogage. Le débogage a été accroché. La Configuration est comme suit

    Hôte: Ubuntu 12.04 LTS

    IDE: Eclipse Kepler

    Cible: Beaglebone Black /ARM A8

    OS: Angstrom

    Solution

    Mise à jour des bibliothèques et comprend

    Sélectionnez propriétés pour le projet dans Eclipse

    • C/C++ Général > les Chemins et les Symboles > (ONGLET inclure) GNU C > Ajouter > Fichiers
      systèmes > /> usr Changement à partir de /usr/lib/gcc/i686-linux-gnu/4/6/inclure
      /usr/arm-linux-gnueabi/include

    • C/C++ Général > les Chemins et les Symboles > (ONGLET Inclure) GNU C++> Ajouter >

      Les systèmes de fichiers > /> usr /usr/arm-linux-gnueabi/include/c++/4.6.3/arm-linux-gnueabi

    • C/C++ Général > les Chemins et les Symboles > (Bibliothèque des Chemins ONGLET) > Ajouter > Fichiers
      systèmes > /> usr /usr/arm-linux-gnueabi/lib

    OriginalL'auteur Mahendra Gunawardena

  4. 0

    Bonne journée,

    Si le 'debug-fichier-répertoire de" variable dans GDB est mal réglé,
    ensuite, les messages d'erreur signalés contient:
    avertissement: Impossible de trouver l'éditeur de liens dynamiques point d'arrêt de la fonction.

    La racine du système de fichiers de la cible se trouve sur mon PC hôte à
    /opt/arm-linux-gnueabihf-rootfs

    Les deux commandes suivantes m'a aidé à obtenir le débogage à distance de travail
    via gdbserver l'utilisation de GDB (v7.11.1):

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

    J'ai remarqué que si 'sysroot' a une barre oblique dans le chemin,
    puis GDB ne parvient pas à l'utiliser.Vous allez voir ceci (sortie incorrecte) après la connexion à la cible à distance:

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

    ou

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

    au lieu de le corriger de sortie:

    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.

    Ce qui concerne,
    Frikkie Thirion

    OriginalL'auteur Frix