Comment ajouter un répertoire au chemin de la bibliothèque lors du chargement d'un fichier core dans gdb sous Linux

Question

J'ai un fichier de base généré sur un système distant auquel je n'ai pas d'accès direct. J'ai également des copies locales des fichiers de la bibliothèque du système distant et le fichier exécutable du programme en panne.

Je voudrais analyser ce dump de base dans gdb.

Par exemple:

gdb path/to/executable path/to/corefile

Mes bibliothèques sont dans le répertoire en cours.

Dans le passé, j'ai vu des débogueurs implémenter ceci en fournissant l'option " ;-p. " ou " ;-p /=." ;; donc ma question est:

Comment puis-je spécifier que les bibliothèques doivent d'abord être chargées à partir de chemins relatifs à mon répertoire actuel lors de l'analyse d'un fichier core dans gdb?

Answer 1

Démarrez gdb sans spécifier l'exécutable ni le fichier core, puis tapez les commandes suivantes:

set solib-absolute-prefix ./usr
file path/to/executable
core-file path/to/corefile

Vous devez vous assurer de refléter exactement le chemin de votre bibliothèque à partir du système cible. Ce qui précède est destiné aux cibles de débogage qui ne correspondent pas à votre hôte. C’est pourquoi il est important de répliquer la structure de votre système de fichiers racine contenant vos bibliothèques.

Si vous êtes en train de déboguer à distance un serveur de même architecture et version Linux / glibc que votre hôte, vous pouvez le faire en fd a suggéré:

set solib-search-path <path>

Si vous essayez de remplacer certaines des bibliothèques, mais pas toutes, vous pouvez copier la structure de répertoires des bibliothèques cibles dans un emplacement temporaire et utiliser la solution solib-absolute-prefix décrite ci-dessus.

Answer 2

Je ne suis pas sûr que cela soit possible dans gdb, mais je ne suis pas un expert.

Cependant, je peux commenter l'éditeur de liens dynamique Linux . Les éléments suivants doivent afficher le chemin de toutes les bibliothèques partagées résolues et non résolues.

ldd path/to/executable

Nous devons savoir comment vos bibliothèques partagées ont été liées à votre exécutable. Pour ce faire, utilisez la commande suivante:

readelf -d path/to/executable | grep RPATH

• Si la commande n'imprime rien, l'éditeur de liens dynamique utilisera les emplacements standard plus la variable d'environnement LD_LIBRARY_PATH pour rechercher les bibliothèques partagées.

• Si la commande affiche certaines lignes, l’éditeur de liens dynamique ignorera LD_LIBRARY_PATH et utilisera à la place les rpath codés en dur.

  Si les chemins d'accès répertoriés sont absolus, la seule solution que je connaisse consiste à copier (ou à créer un lien symbolique) vos bibliothèques aux emplacements indiqués.

  Si les chemins d'accès répertoriés sont relatifs, ils contiendront un $ ORIGIN qui sera remplacé au moment de l'exécution par le chemin de l'exécutable. Déplacez l'exécutable ou les bibliothèques pour qu'elles correspondent.

Pour plus d'informations, vous pouvez commencer par:

man ld.so

Answer 3

J'ai trouvé cet extrait sur developer.apple.com

set solib-search-path path

     

Si cette variable est définie, path est un   liste de répertoires séparés par deux points   rechercher des bibliothèques partagées.    solib-search-path 'est utilisé après    solib-absolute-prefix 'échoue   localiser la bibliothèque, ou si le chemin d'accès à   la bibliothèque est relative au lieu de   absolu. Si vous voulez utiliser    solib-search-path 'au lieu de    solib-absolute-prefix ', assurez-vous de   placez `solib-absolute-prefix 'à un   répertoire non existant pour empêcher la GDB   de trouver les bibliothèques de votre hôte.

EDIT:

Je ne pense pas que l’utilisation du paramètre ci-dessus ajoute des préfixes aux répertoires que j’ai ajoutés, mais il semble que ceux-ci les ajoutent. Par conséquent, les fichiers manquants dans mon système actuel sont récupérés dans les chemins que j’ai ajoutés. Je suppose que fixer le préfixe absolu-solib à quelque chose de faux et ajouter des répertoires dans le chemin-recherche-solib dans l'ordre dont j'ai besoin pourrait être une solution complète.

Answer 4

Vous pouvez également simplement définir LD_PRELOAD sur chacune des bibliothèques ou LD_LIBRARY_PATH sur le répertoire en cours lors de l'appel de gdb. Cela ne posera problème que si gdb essaie lui-même d’utiliser l’une des bibliothèques sur lesquelles vous préchargez.

Answer 5

Une note importante:

si vous faites une compilation croisée et essayez de déboguer avec gdb, alors une fois que vous avez terminé, fichier ECECUTABLE_NAME si vous voyez smth. comme:

Using host libthread_db library "/lib/libthread_db.so.1"

puis vérifiez si vous avez libthread_db pour votre système cible. J'ai trouvé beaucoup de problèmes similaires sur le web. Un tel problème ne peut pas être résolu en utilisant simplement "set solib-", vous devez aussi construire libthread_db en utilisant votre compilateur croisé.