Erreur "Aucune source disponible pour main ()" lors du débogage de C++ simple dans Eclipse avec gdb
Je ne parviens pas à déboguer un programme C++ dans Eclipse (le dernier RC de Helios, mis à jour avec le dernier CDT à partir de lui-même) sous OSX.
Le programme est très simple (essentiellement la leçon 2 tirée des didacticiels OpenGL de NeHe), consistant en un fichier cpp et, à l'aide des frameworks OpenGL et Cocoa, et en liaison avec libSDL.a et libSDLmain.a.
La structure du projet est très simple: le (s) fichier (s) source (s) se trouvent dans un sous-répertoire du projet appelé src/et l'exécutable est construit dans le répertoire racine du projet.
Le problème est que, chaque fois que j'essaie d'ajouter des points d'arrêt et de les déboguer, ils semblent être parfaitement touchés, mais aucune source n'est affichée. À la place, une erreur "Aucune source disponible pour main ()" apparaît dans la fenêtre de code.
Les indicateurs du compilateur ont des optimisations définies sur none, et le compilateur et l'éditeur de liens ont tous les deux l'indicateur des symboles de débogage (-g).
Le paramètre de débogage dans Eclipse est défini sur "Progrès standard d'apparition" et le débogueur sur "gdb".
La chose la plus étrange est que si j'essaie de déboguer le même exécutable - c'est-à-dire. le même qui a été construit par Eclipse - en utilisant gdb à partir du terminal (Shell), puis tout fonctionne bien. Les points d'arrêt sont touchés, le code source est affiché, aucun problème.
Je me suis assuré que Eclipse et le shell utilisent le même exécutable gdb, et ils le sont (il s'agit de/usr/bin/gdb).
Maintenant, je me trompe peut-être, mais tout cela me suggère que les indicateurs du compilateur et de l'éditeur de liens ne posent aucun problème (parce que le même exécutable est débogable depuis le shell). Le problème est donc probablement dû à la manière dont gdb est invoqué. depuis Eclipse? Peut-être que lorsqu'il est exécuté depuis Eclipse, gdb récupère différents fichiers de configuration ou quelque chose de différent de celui utilisé à partir du shell? (Quelqu'un sait?)
J'apprécierais vraiment toute aide avec ceci parce que cela me conduit lentement en boucle!
Faites-moi savoir s'il existe d'autres détails qui pourraient être utiles - numéros de version exacts de Eclipse/cdt/gdb, lignes de commande exactes pour l'éditeur de liens/compilateur, etc. - et je mettrai très volontiers à jour cet article avec eux.
Merci d'avance,
gracieuseté de.
---édité @ "Il y a 14 heures"---
J'ai essayé l'option "ajouter un chemin de système de fichiers" (avec "recherche de sous-dossiers"), mais cela n'a pas fonctionné. J'ai également essayé de créer un nouveau projet complètement plat, mais cela ne fonctionnait pas non plus . J'ai même essayé d'obtenir une version de Galileo (Eclipse-SDK-3.5.2RC4 avec mise à jour CDT), mais cela ne faisait aucune différence (à part gdb être plus lent à se lancer).
Et voici quelque chose d'autre d'étrange que j'ai remarqué: une fois que je reçois le message "Aucune source disponible", si je change alors de console Eclipse pour afficher la console "gdb", et active également le "mode console Verbose" afin que je puisse le communiquer, je peux puis émettez les commandes "l" et "bt" et faites-les fonctionner avec succès, en indiquant la source et la pile correctes où mon point d'arrêt a été touché. Ce qui, corrigez-moi si je me trompe, doit signifier que les informations sont là et que gdb est invoqué correctement - alors pourquoi Eclipse ne voit-il pas ces informations?
Pour être honnête, je suis sur le point d'abandonner Eclipse ... J'y suis arrivé avec de grands espoirs.
Toute aide ou pensée supplémentaire serait extrêmement appréciée.
t.
J'ai trouvé la réponse! Et c'est d'une simplicité embarrassante.
Le problème était que j'utilisais la version Release de SDL au lieu de la version Debug! (J'ai eu 'libsdl' de MacPorts alors que j'aurais dû 'libsdl-devel'.)
Ma réponse générique est donc la suivante: assurez-vous que les bibliothèques sur lesquelles vous liez ont été compilées avec les indicateurs de débogage définis, il ne suffit pas toujours de vous assurer que votre propre code les a définies.
Ce fil suggère:
-g -O0
pour que les indicateurs de débogage soient définis pour la compilation Eclipse CDT.
Parfois, il est simple de reconstruire complètement l’application ( comme ici )
Voir aussi ce fil décrivant une situation similaire:
J'ai remarqué que parfois dans Eclipse, je devais y aller et ajouter spécifiquement le chemin d'accès à mes fichiers sources en utilisant le "
add filesystem path" (avec "search sub-folders") dans la boîte de dialogue Débogage (même s'ils sont dans le même projet que je débogue), Je n'ai pas remarqué de tendance à ce moment-là. Mais cela vaut peut-être la peine d'essayer.
Voici une autre raison de ce problème. Ma configuration utilisait l'option -g3 de gcc. Le changer en -g a résolu le problème. Il semble y avoir une certaine incompatibilité entre gcc et gdb. J'ai vérifié que gdb était la dernière révision (en utilisant apt-get).
Je voudrais ajouter un peu de sang neuf à ce vieux fil.
J'ai rencontré ce problème lorsque j'ai essayé de compiler et de déboguer un projet Gnu Arm.
J'ai résolu le problème en modifiant le Makefile: En ajoutant "-g -O0" à la fin de cette ligne "CFLAGS + = -Wall -Werror -O3"
Allez à Propriétés du projet, C/C++ Construire -> Paramètres. Dans le premier onglet (Paramètres de l’outil), sous Compilateur GCC croisé, cliquez sur Débogage et définissez Niveau de débogage sur Maximum (-g3)
J'avais ce problème lorsque j'ai compilé le dernier gcc, mais je n'ai pas mis à jour le dernier gdb. Après la mise à jour, cela a fonctionné correctement.
Si vous utilisez cmake pour construire le projet, une solution à la solution consiste à ajouter le "drapeau de débogage" à la commande cmake, c'est-à-dire -
$ cmake/path/to/main/cmake_file -DCMAKE_BUILD_TYPE=Debug
Pour toute autre personne susceptible de rencontrer ce problème,
J'ai installé le plugin linuxtools/valgrind hier soir pour faire un profilage de la mémoire, et il semble que cela ait brisé le gdb normal. Quand j'ai supprimé les plugins linuxtools, tout a recommencé à fonctionner normalement.
Donc, vous voudrez peut-être essayer cela.
J'avais un problème similaire. J'utilisais CFLAGS=-Wall -O2 -fPIC -DPIC -lm -lasound et je n'ai jamais eu de problème pour le compiler, mais lorsque j'ai essayé de le déboguer sur Eclipse IDE, le message d'erreur suivant s'affiche: No source available for "main() at 0x401080", puis j'ai ajouté -g à cette ligne.
CFLAGS = -g -Wall -O2 -fPIC -DPIC -lm -lasound
Ce problème dépend de la façon dont gdb est appelé. J'ai trouvé que je devais spécifier manuellement les emplacements des fichiers source lorsque j'ai eu cette erreur. Même si j'avais déjà configuré cela sous les propriétés du projet. Après cela, Eclipse n'a plus eu de problème pour fournir la source appropriée.
L'utilisation de la version reliée à la version debug d'une bibliothèque peut être votre problème spécifique (si vous construisiez une bibliothèque à partir de la source puis la déboguiez). Si une personne utilise une bibliothèque précompilée, elle ne pourra jamais définir de points d'arrêt à l'intérieur de celle-ci et ce correctif ne lui sera donc pas applicable.
A rencontré le même problème une fois. Vous devez simplement aller dans les propriétés de votre projet, en appuyant sur ALT + ENTR ou par un clic droit sur le projet et faites défiler vers le bas pour trouver les propriétés. Développez la compilation C/C++ à gauche. Puis cliquez sur paramètres. Une fois les paramètres ouverts, cliquez ensuite sur les paramètres de l’outil. Dans le MCU GCC Compiler, il existe une option de débogage. Cliquez sur le débogage et ajoutez
-g -O0
dans les autres drapeaux de débogage. Essayer de déboguer le projet maintenant.
Je viens juste de faire face à ce problème et après avoir pris un certain temps pour le découvrir, je me suis rendu compte que les arguments Arguments et Principal de la boîte de dialogue Configurations de débogage sont en conflit.
Assurez-vous que les arguments d'application et de programmes C/C++ pointent vers le même fichier binaire.