2010-11-27 24 views
8

Je commence à en avoir marre de devoir garder mon code source intact jusqu'à ce que j'aie terminé son débogage. Chaque fois que je change mon code, GDB commence à se plaindre à ce sujet:Incorporation du code source d'un programme dans son binaire en utilisant GCC pour l'utilisation ultérieure de GDB

avertissement: le fichier source est plus récent que l'exécutable.

jusqu'à ce que je le recompile, ce qui ne peut pas toujours être fait rapidement. Je pense que ce serait génial s'il était possible d'inclure le code source d'un programme dans son binaire et de faire en sorte que GDB l'utilise à la place de sa version à jour.

Quelqu'un pourrait-il suggérer un moyen de le faire? Cela a-t-il été mis en œuvre du tout?

Répondre

3

GCC est open source - vous pouvez le réparer. Bien sûr, vous devrez probablement réviser LD pour gérer correctement les informations, et vous devrez certainement corriger GDB pour utiliser la source intégrée. Vous utiliseriez un format non standard pour les informations de débogage, vous devrez donc probablement modifier les autres outils qui manipulent les fichiers objets.

Donc, la possibilité est là. Mais il est plus facile de faire la même chose que tout le monde dans le monde et de garder votre source jusqu'à ce que vous ayez fini de le déboguer. Normalement, vous pouvez garder une seule session GDB en cours d'exécution pendant que vous reconstruisez l'exécutable plusieurs fois, si besoin est. Et, typiquement, il est plus facile de déboguer la version actuelle du code plutôt que la version d'hier. Si vous avez besoin de déboguer la version d'hier, vous avez besoin du code d'hier disponible (vous avez un bon VCS en place, n'est-ce pas?) Afin de voir ce qui ne va pas avec le code d'hier plutôt que la version modifiée du code .

Je vous donnerai le mérite de poser la question - il faut une réflexion latérale pour trouver l'idée. Bien joué! Mais en pratique, votre suggestion est décidément non triviale à mettre en œuvre.

+0

Sûrement je n'ai pas assez de temps/compétence/patience/nécessité de l'implémenter comme une nouvelle fonctionnalité, cependant, je suis assez surpris qu'il n'a pas encore été implémenté. Bien que je sois d'accord que dans la plupart des cas, il ne devrait pas être nécessaire, il peut parfois être utile. Par exemple, je démarre un débogueur avec mon ancien fichier binaire pour trouver ce qui ne va pas. Je localise la source du problème, mais juste après avoir écrit la moitié du code et l'avoir sauvegardé, la session GDB se bloque en raison d'une simple faute de frappe. Maintenant, je vais soit devoir corriger le code sans l'aide du débogueur ou revenir en arrière, reconstruire le programme, exécuter GDB et annuler les changements! – undercat

+0

@vovick: il y a au moins deux raisons. L'un est historique: les ressources abondantes disponibles maintenant n'étaient pas toujours disponibles, et les gens pensaient (probablement à juste titre) qu'il valait mieux ne pas encombrer le code débogable avec la source réelle car cela nécessiterait trop d'espace disque et de mémoire. Autrefois, il était déjà assez difficile de mémoriser le programme - sans parler d'ajouter les informations de débogage supplémentaires, etc. L'autre est pratique: les gens ne trouvent pas si difficile de garder la source disponible pour justifier l'effort dans le faire comme vous le suggérez. –