Surmonter dans Emacs GDB

Question

J'ai du mal à passer dans GDB. J'ai construit un exemple de programme à partir de la bibliothèque ffmpeg avec des symboles de débogage et de déconnexion. Bien que j'ai configuré la bibliothèque ffmpeg à statique et explicitement désactivé partagé, il semble que le programme que je débogue relie dynamiquement, puisque sa taille de fichier est seulement de 99 Ko. Je ne sais pas que c'est le problème mais je pensais le mentionner.

Après avoir défini et atteint un point d'arrêt dans av_seek_frame, j'utilise la commande 'next' pour passer la souris. Cependant, cela va dans la première fonction de av_seek_frame(), comme vous pouvez le voir ci-dessous. De plus, si vous faites une seconde "prochaine", la trace perd sa trace. Est-ce que je me suis trompé? Comment puis-je passer par-dessus? Je dois souligner que je double vérifié que « pas en mode déclenché » est désactivé par défaut (comme je crois que cela va casser au premier morceau de code sans informations de débogage.)

Breakpoint 1, av_seek_frame (s=0x16429000, stream_index=0, timestamp=29727438, flags=0) at l 
(gdb) list 
1648 
1649  return 0; 
1650 } 
1651 
1652 int av_seek_frame(AVFormatContext *s, int stream_index, int64_t timestamp, int flags 
1653 { 
1654  int ret; 
1655  AVStream *st; 
1656 
1657  ff_read_frame_flush(s); 
(gdb) next 
ff_read_frame_flush (s=0x16429000) at libavformat/utils.c:1248 
(gdb) list 
1243 
1244 /** 
1245  * Flush the frame reader. 
1246  **/ 
1247 void ff_read_frame_flush(AVFormatContext *s) 
1248 { 
1249  AVStream *st; 
1250  int i, j; 
1251 
1252  flush_packet_queue(s); 
(gdb) next 
ff_read_frame_flush (s=0x16429000) at libavformat/utils.c:1252 
(gdb) where 
#0 ff_read_frame_flush (s=0x16429000) at libavformat/utils.c:1252 
#1 0x00000000 in ??() 

Answer 1

Si vous n'êtes pas sûr si oui ou non votre binaire est lié statiquement, vous pouvez vérifier avec ldd et voir un message comme celui-ci:

% ldd ffmpeg 
     not a dynamic executable 

Ensuite, assurez-vous que vous donnez gdb le chemin complet vers le fichier exécutable de sorte que vous n'êtes pas accidentellement ramasser un binaire installé ailleurs sur le système qui se trouve dans votre PATH.

Il est fort probable que vous chargiez le mauvais binaire. sans en utilisant --disable-stripping et --disable-optimizations Je peux utiliser gdb très bien en utilisant les commandes step et next. Vous n'avez pas besoin d'utiliser --disable-stripping car dans gdb vous pouvez utiliser le binaire ffmpeg_g (ou si vous exécutez le binaire ffmpeg, vous pouvez en charger les symboles en utilisant file ffmpeg_g). Pour le débogage, il est bon d'utiliser les options --disable-optimizations pour ne pas avoir value optimized out lors de l'inspection des variables, mais vous n'avez pas besoin d'utiliser l'option pour que emacs/gdb se comporte correctement. .. Je n'ai aucun problème à parcourir le code lorsque des optimisations sont utilisées. Cependant, lorsque vous définissez des points d'arrêt avec gud/gdb dans Emacs, vous risquez de créer une confusion: la commande gud-break n'utilise que la partie de base du nom de fichier pour définir les points d'arrêt, pas le chemin absolu à lui, qui dans le cas de ffmpeg signifie que si, par exemple, vous définissez un point d'arrêt dans utils.c il peut ne pas fonctionner correctement selon la valeur des chemins de recherche de code source que vous avez définis dans gdb parce que ffmpeg a plusieurs fichiers nommé utils.c dans différents chemins (en fait, il y a un total de 5 fichiers utils.c, un dans chacun des sous-répertoires lib *). Par défaut, le chemin de recherche est défini sur $ cdir: $ cwd, mais si vous l'avez défini sur/path/to/ffmpeg: $ cdir: $ cwd et que vous essayez de définir un point d'arrêt dans utils.c de libavformat, il pourrait trouver celui dans libavutil-- auquel cas si vous avez de la chance il se plaindra que la ligne où vous voulez définir un point d'arrêt n'existe pas (parce que celle dans libavutil est plus courte), ou il pourrait définir un point d'arrêt sur la ligne que vous voulez, mais dans le mauvais utils.c.

Ce problème avec gud/gdb devrait être considéré comme un bug. Quand je reçois un moment je vais soumettre un patch pour gud-break/gud-format-commande pour résoudre le problème.