Comment préfixer un répertoire le chemin de la bibliothèque lors du chargement d'un fichier core dans gdb sous Linux?

Question

J'ai un fichier core généré sur un système distant auquel je n'ai pas directement accès. J'ai également des copies locales des fichiers de bibliothèque à partir du système distant, et le fichier exécutable pour le programme de plantage.

Je voudrais analyser cette image de base dans gdb.

Par exemple:

gdb path/to/executable path/to/corefile 

Mes bibliothèques sont dans le répertoire courant.

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

Comment puis-je spécifier que les bibliothèques soient chargées en premier à partir des chemins relatifs à mon répertoire courant lors de l'analyse d'un corefile dans gdb?

Answer 1

Démarrer gdb sans spécifier le fichier exécutable ou noyau, 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 votre chemin de la bibliothèque exactement du système cible. Ce qui précède est destiné à déboguer des cibles 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 le débogage à distance un serveur qui est la même architecture et Linux/glibc que votre hôte, vous pouvez le faire comme fd suggéré:

set solib-search-path <path> 

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

Answer 2

Je trouve cet extrait sur developer.apple.com

set solib-search-path path 

Si cette variable est définie, le chemin est une liste séparée du côlon- des répertoires à chercher les bibliothèques partagées. solib-search-path' is used after solib-absolute-prefix 'échoue à localiser la bibliothèque, ou si le chemin vers la bibliothèque est relatif au lieu de absolu. Si vous souhaitez utiliser solib-search-path' instead of solib-absolute-prefix ', assurez-vous que définissez `solib-absolute-prefix' sur un répertoire nonexistant pour empêcher GDB de trouver les bibliothèques de votre hôte.

EDIT:

Je ne pense pas en utilisant le paramètre ci-dessus prepends les répertoires que j'ai ajouté, mais il ne semble les ajouter, de sorte que les fichiers manquants de mon système actuel sont repris dans les chemins J'ai ajouté. Je suppose que mettre le préfixe solib-absolute à quelque chose de bidon et ajouter des répertoires dans le solib-search-path dans l'ordre dont j'ai besoin pourrait être une solution complète.

Answer 3

Je ne suis pas sûr que ce soit possible du tout au sein de gdb mais je ne suis pas un expert.

Cependant, je peux commenter l'éditeur de liens dynamiques Linux. Les éléments suivants doivent imprimer le chemin de toutes les bibliothèques partagées résolues et celles qui n'ont pas été résolues.

ldd path/to/executable 

Nous avons besoin de 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 rien d'impression de commande, l'éditeur de liens dynamique utiliser des emplacements standard, plus la variable d'environnement LD_LIBRARY_PATH pour trouver les bibliothèques partagées.

• Si la commande imprime certaines lignes, l'éditeur de liens dynamiques ignorera LD_LIBRARY_PATH et utilisera plutôt les rpaths codés en dur.

  Si les rpaths listés sont absolus, la seule solution que je connaisse est de copier (ou de créer un lien symbolique) vos bibliothèques vers les emplacements listés.

  Si les chemins rpath 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 correspondant.

Pour plus d'informations, vous pouvez commencer par:

man ld.so 

Answer 4

Une note importante:

si vous faites une compilation croisée et d'essayer de déboguer avec gdb, puis après vous avez fait
file ECECUTABLE_NAME si vous voyez le ch. comme:

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

Ensuite, 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 simplement en utilisant "set solib-", vous devez aussi construire libthread_db en utilisant votre compilateur croisé.

Answer 5

Vous pouvez également 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 causera des problèmes que si gdb tente d'utiliser l'une des bibliothèques que vous préchargez.