web-dev-qa-db-fra.com

LLDB ne montrant pas le code source

J'essaie de déboguer un programme C++ que j'écris, mais quand je l'exécute en LLDB et arrête le programme, il ne me montre que l'assembleur, pas la source d'origine. par exemple. après le crash, j'essaie de déboguer:

Process 86122 stopped
* thread #13: tid = 0x142181, 0x0000000100006ec1 debug_build`game::update() + 10961, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x0000000100006ec1 debug_build`game::update() + 10961
debug_build`game::update:
->  0x100006ec1 <+10961>: movq   (%rdx), %rdx
    0x100006ec4 <+10964>: movq   %rax, -0xb28(%rbp)
    0x100006ecb <+10971>: movq   -0x1130(%rbp), %rax
    0x100006ed2 <+10978>: movq   0x8(%rax), %rsi

Je compile avec -O0 -g. Je vois la même chose lors de l'exécution du débogueur via Xcode (je suis sur OSX) ou depuis la ligne de commande.

Que dois-je faire d'autre pour que le code source s'affiche en LLDB?

Notes supplémentaires

Voici un exemple de commande de génération typique:

clang++ -std=c++1y -stdlib=libc++ -fexceptions -I/usr/local/include -c -O2 -Wall -ferror-limit=5 -g -O0 -ftrapv lib/format.cpp -o format.o

Le premier -O2 Est là parce que c'est la valeur par défaut que j'utilise, mais je pense que le dernier -O0 Le remplace, non?

Ce que j'ai essayé

  1. J'ai recréé ce problème avec un simple programme "hello world" utilisant les mêmes paramètres de construction.

  2. Après quelques recherches, j'ai essayé d'exécuter dsymutil main.o Qui disait warning: no debug symbols in executable (-Arch x86_64), alors peut-être que les symboles de débogage ne sont pas générés par mes commandes de construction?

  3. J'ai également essayé d'ajouter -gsplit-dwarf Aux commandes de build mais sans effet.

  4. Voici la commande de lien de ma version ‘hello world’:

    clang ++ main.o -L/usr/local/lib -g -o bonjour

  5. J'ai exécuté dwarfdump ( j'ai lu à ce sujet ici ) sur les fichiers exécutables et objets. Il semble à mes yeux inexpérimentés que les symboles de débogage sont présents dans les fichiers objets, mais pas dans l'exécutable lui-même (à moins que dwarfdump ne fonctionne que sur les fichiers objets, ce qui est possible) . Alors peut-être l'étape de liaison est le problème. Ou peut-être qu'il y a un problème avec le DWARF.

  6. Je l'ai maintenant fait fonctionner dans le programme "hello world", en émettant des commandes de construction une par une dans le terminal. Je suppose donc que cela peut être un problème avec mon système de construction ( Tup ), éventuellement en exécutant les commandes avec un répertoire de travail différent afin que les chemins soient altérés ou quelque chose.

c++lldbclang++tup
21
Leo

Lorsque vous ajoutez l'option de ligne de commande -g à clang, les informations de débogage DWARF sont placées dans le fichier .o. Lorsque vous liez vos fichiers objets (.o, Archives ranlib alias bibliothèques statiques alias .a Fichiers) dans un exécutable/dylib/framework/bundle, des "notes de débogage" sont placées dans l'exécutable pour indiquer ( 1) l'emplacement des fichiers .o Etc avec les informations de débogage, et (2) les adresses finales des fonctions/variables dans le binaire exécutable. Les drapeaux d'optimisation (-O0, -O2, Etc.) n'ont pas d'impact sur la génération d'informations de débogage - bien que le code de débogage compilé avec l'optimisation soit beaucoup plus difficile que le code de débogage construit à -O0.

Si vous exécutez le débogueur sur ce binaire exécutable - sans aucune autre modification - le débogueur lira les informations de débogage des fichiers .o Etc ( tant que ils sont toujours sur le système de fichiers au même chemin de fichier lorsque vous avez construit l'exécutable . Cela rend le développement itératif rapide - aucun outil n'a besoin de lire, mettre à jour et sortir les (grandes) informations de débogage. Vous pouvez voir ces "notes de débogage" dans l'exécutable en exécutant nm -pa exename Et en recherchant OSO entrées (entre autres). Il s'agit d'entrées stablist nlist et l'exécution de strip(1) sur votre exécutable les supprimera.

Si vous souhaitez collecter toutes les informations de débogage (dans les fichiers .o) Dans un ensemble autonome, vous exécutez dsymutil sur l'exécutable. Cela utilise les notes de débogage (hypothèses: (1) les fichiers .o Sont toujours à leur emplacement d'origine et (2) l'exécutable n'a pas été supprimé) pour créer un "dSYM bundle". Si le binaire est exename , le bundle dSYM est exename.dSYM . Lorsque le débogueur est exécuté sur exename , il cherchera à côté de ce binaire pour le bundle dSYM. S'il n'y est pas trouvé, il effectuera une recherche Spotlight pour voir si le dSYM se trouve dans un emplacement indexé Spotlight sur votre ordinateur.

Vous pouvez exécuter dwarfdump sur des fichiers .o Ou sur le bundle dSYM - ils contiennent tous deux des informations de débogage. dwarfdump ne trouvera aucune information de débogage dans votre exécutable de sortie.

Donc, le flux de travail normal: compilez avec -g. Lier l'image exécutable. En cas de développement itératif, exécutez le débogueur. Si vous expédiez/archivez le binaire, créez dSYM, supprimez l'exécutable.

23
Jason Molenda

Je l'ai résolu en ajoutant le chemin d'accès aux symboles de débogage qui sont présents dans le répertoire a.out.dSYM en utilisant (lldb) target symbols add a.out.dSYM commande.

3
Avishek Chowdhury