Obtention d'une trace de pile à partir de GDB

Question

Je dois avoir une mauvaise compréhension de la pile, ou comment les fonctions sont appelées, les résultats de backtrace que je reçois de GDB n'ont aucun sens pour moi. J'essaie de savoir où les choses sont appelées dans un programme afin que je puisse ajouter mon composant. L'outil dessine des limites sur des vidéos, ce que j'ai fait est un interpolateur. Je pensais que ça avait du sens d'ouvrir GDB et de mettre un point d'arrêt quand une boîte était en train d'être tracée, et de faire un backtrace. Voici la sortie de mu (après l'exécution du programme de ffmpeg.c main())

#0 draw_glyphs (vidatbox=0x10183d200, picref=0x10141e340, width=720, height=480, 
rgbcolor=0x10183d284 "????", yuvcolor=0x10183d278 "뀀?\020???\020???????", x=0, y=0) at 
libavfilter/vf_VidAT.c:627 
#1 0x000000010001ce4c in draw_text (ctx=0x10120df20, picref=0x10141e340, width=720, 
height=480) at libavfilter/vf_VidAT.c:787 

Abstraction faite de tous les caractères non-ascii, comment sont les deux fonctions draw_glyphs et draw_text être appelé? Comment se fait il n'y a rien d'autre sur la pile? Quand je choisis il me dit cadre # 1 et essayer d'aller up,:

Initial frame selected; you cannot go up. 

EDIT:

Je l'ai regardé plus, et je suis encore plus confus alors j'étais quand je demandé. La fonction draw_glyphs n'est même pas appelée à l'intérieur de la ligne principale que je cours. J'ai parcouru tous les fichiers que cela utilise pour compiler et bien ... il n'est pas appelé n'importe où! Est-ce que cela signifie que c'est un pointeur de fonction créé dynamiquement ou quelque chose? Si oui, cela rendrait-il la pile inaccessible comme la mienne?

Answer 1

Si la trace de la pile est informative mais s'arrête de manière inattendue (en particulier après une ou deux entrées seulement), cela indique que gdb n'a pas pu suivre la pile d'appels après ce point.

Les options du compilateur qui interfèrent avec le déroulement de la pile incluent des niveaux d'optimisation plus élevés (en particulier -O3) et , alors recherchez vos Makefiles et supprimez ces options. Le frame pointer n'est généralement pas nécessaire à l'exécution du code, donc l'utiliser comme un registre général améliorera les performances sur les architectures affamées par le registre telles que x86, mais peut interférer avec le débogage.

Plus récemment, le déroulement de la pile à base de trame est remplacé par unwind tables, mais gdb repose toujours sur le pointeur de cadre si les tables de déroulement ne sont pas présentes.