Seer : une interface graphique pour GDB sous Linux

 (github.com/epasveer)
3 points par GN⁺ 2024-11-16 | 1 commentaires | Partager sur WhatsApp
  • Seer est un frontend permettant de piloter GDB via une interface graphique sous Linux, activement développé avec pour objectif de proposer une GUI simple et agréable pour GDB
  • L’installation est possible via un gestionnaire de paquets ou en compilant depuis les sources, avec comme prérequis Linux, C++17, GDB avec prise en charge de l’interpréteur MI, CMake 3.5.0 ou plus récent, et Qt6
  • Qt5 ne se compile plus avec l’arborescence source la plus récente ; l’arborescence 2.3 est la dernière compatible avec Qt5, et la v1.17 est la dernière version publiée sous Qt5
  • Seer fournit dans son interface la navigation dans le code source, l’affichage des variables et registres, la gestion des breakpoints, watchpoints, catchpoints et printpoints, la vue pile et threads, ainsi que le reverse debugging de GDB
  • Parmi les fonctions supplémentaires figurent la vue assembleur, la visualisation de la mémoire, des tableaux, des structures et des images, ainsi qu’une console d’entrée/sortie du programme, pour rendre le débogage GDB plus visuel

Aperçu du projet

  • Seer est une interface graphique frontend pour GDB sous Linux
  • Son objectif est de proposer à GDB une GUI simple et agréable à utiliser
  • Le projet est activement développé, et il est possible de signaler des bugs ou de demander des fonctionnalités par e-mail ou via les issues GitHub

Installation et prérequis

  • Seer peut être installé via un gestionnaire de paquets ou par compilation depuis les sources
  • Prérequis :
    • Linux
    • C++17
    • GDB avec prise en charge de l’interpréteur mi
      • Commande de vérification : gdb --interpreter=mi
    • CMake 3.5.0 ou version ultérieure
    • Qt6
      • En cas de compilation depuis les sources, les paquets de développement Qt6 adaptés à la distribution sont nécessaires
      • Les modules Qt6 requis sont Core, Gui, Widgets, PrintSupport, Charts et Svg
      • Guide de compilation Qt6 : Building Seer - Qt6
  • Limitations liées à Qt5 :

    • Seer ne se compile plus avec Qt5

      • L’arborescence source 2.3 est la dernière à pouvoir être compilée avec Qt5
      • Guide de compilation Qt5 : Building Seer - Qt5

Canaux d’installation par paquet

  • Pamac sur Manjaro :
    • pamac install seer
  • zypper sur openSUSE Tumbleweed :
    • zypper install seergdb
  • Flathub :
  • Version bêta Flatpak :
    • Seer release page
    • télécharger puis installer seer.flatpak
    • flatpak-spawn --host est requis pour lancer GDB depuis GDB Launcher

Versions et transition vers Qt

  • Les nouveautés peuvent être suivies sur le Seer Wiki
  • v1.17 est la dernière version publiée sous Qt5
  • La version suivante est la v2.0, basée sur Qt6
  • Pendant quelque temps, la compilation avec Qt5 reste possible, mais si vous avez besoin de la dernière base source stable sous Qt5, il faut utiliser v1.17

Mode de lancement

  • Seer est conçu pour faciliter le démarrage du programme à déboguer depuis la ligne de commande
  • Comme GDB prend en charge plusieurs façons de déboguer un programme, Seer propose lui aussi plusieurs modes de lancement
  • Les méthodes de lancement sont décrites dans le wiki Starting Seer

Organisation de l’interface principale

  • Source/Function/Types/Variables/Libraries

    • affiche la liste des fichiers source et d’en-tête utilisés dans le programme
    • permet de rechercher les fonctions, types et variables statiques
    • un double-clic permet d’ouvrir un fichier source
    • affiche la liste des bibliothèques partagées référencées par le programme
    • la liste des fichiers source et d’en-tête peut être filtrée par recherche

  • Variable/Register Info

    • affiche les valeurs des variables et des registres
    • Logger enregistre les valeurs de variables
    • Tracker affiche les valeurs des variables choisies chaque fois que GDB atteint un point d’arrêt comme step, next ou finish
    • Registers affiche les valeurs de tous les registres CPU

  • Code Manager

    • grande zone centrale de l’interface Seer, affichant les fichiers source dans des onglets
    • ^F permet de rechercher du texte dans le fichier
    • un double-clic sur un nom de variable permet de l’ajouter à Logger
      • CTRL + double-clic ajoute * devant la variable
      • SHIFT + double-clic ajoute & devant la variable
      • CTRL+SHIFT + double-clic ajoute *& devant la variable
    • le menu contextuel permet d’ajouter une variable à Tracker ou au Memory Visualizer
    • permet de créer un breakpoint ou un printpoint sur une ligne donnée
    • permet d’exécuter jusqu’à une ligne précise
    • les onglets peuvent être détachés par double-clic

Contrôle du débogage et vue de l’état d’exécution

  • La zone inférieure gère les breakpoints, watchpoints, catchpoints, printpoints, commandes GDB manuelles et journaux
  • Dans l’onglet des commandes manuelles, il est possible de saisir directement des commandes GDB ou GDB/MI
    • les commandes saisies sont mémorisées pour la prochaine utilisation de Seer
  • Breakpoint manager permet de créer et gérer les breakpoints
  • Watchpoint manager surveille les accès aux variables
    • il peut surveiller la lecture, l’écriture ou lecture+écriture
  • Catchpoint manager arrête l’exécution lors des appels C++ à throw, rethrow et catch
  • Printpoint manager permet d’afficher des variables à un point précis, comme le dprintf de GDB
  • GDB output enregistre la sortie du programme GDB lui-même
  • Seer output enregistre la sortie de diagnostic du programme Seer
  • Informations de pile d’exécution :
    • un double-clic sur la liste des frames permet de changer le scope de la fonction courante
    • affiche les arguments de fonction de chaque frame
    • affiche les valeurs des variables locales de la fonction courante
  • Informations sur les threads :
    • affiche la liste de tous les identifiants de thread
    • un double-clic sur un identifiant de thread permet de changer le scope du thread courant
    • liste les stack frames de chaque thread
  • Prend en charge le mode Reverse Debugging de GDB
    • il est possible d’activer ou désactiver l’historique des commandes
    • la direction de lecture peut être définie sur forward ou reverse

Console et vue assembleur

  • Seer Console affiche toute la sortie texte du programme exécuté
  • L’entrée texte destinée au programme peut également être saisie depuis la console
  • Assembly View ajoute à côté des onglets source un onglet affichant l’assembleur en cours d’exécution
    • s’active via View->Assembly View
    • des breakpoints peuvent aussi être placés dans l’onglet assembleur
    • l’instruction courante est mise en évidence
    • un double-clic sur un élément des onglets Breakpoints ou Stack frames affiche l’assembleur à l’adresse correspondante
    • prend en charge les raccourcis Nexti et Stepi, généralement définis par défaut sur Ctrl+F5 et CTRL+F6
    • utiliser ^F dans l’onglet assembleur affiche une barre de recherche
    • cette fonction assembleur est récente et ouverte aux propositions de modification ou de nouvelles fonctionnalités

Outils de visualisation

  • Memory Visualizer

    • permet d’inspecter le contenu brut de la mémoire
    • permet une vue mémoire et une vue désassemblée

  • Array Visualizer

    • visualise le contenu des tableaux
    • propose les modes d’affichage Normal, Spline et Scatter
    • peut utiliser deux tableaux comme tracé X-Y
    • l’exemple du tableau points forme un contour X-Y

  • Struct Visualizer

    • affiche le contenu d’une structure C/C++ ou d’une classe C++
    • l’exemple montre le contenu de *this pour la classe C++ courante
    • les membres de structure de type de base peuvent être modifiés
    • il existe aussi un Basic Struct Visualizer, plus léger mais incapable de suivre les pointeurs ou de modifier les valeurs

  • Image Visualizer

    • peut être utilisé pour visualiser un contenu mémoire brut représentant une image

Support et contact

  • Les bugs ou demandes de fonctionnalité peuvent être envoyés à epasveer@att.net ou signalés via les issues GitHub
  • Dépôt d’issue : GitHub issues

À lire aussi

1 commentaires

 
GN⁺ 2024-11-16
Avis sur Hacker News

  • Je l’ai compilé avec Godot sous Linux et je l’ai utilisé un peu ; dans l’ensemble c’est correct, mais l’UI donne l’impression d’avoir trop de widgets et semble encore un peu brute
    Le changement de police de l’éditeur ne fonctionnait pas, et quand je passais la souris sur une variable pour voir sa valeur, soit rien ne se passait, soit le curseur changeait très brièvement, puis GDB affichait une erreur disant qu’il avait essayé d’utiliser une expression contenant un type/mot-clé
    Un double-clic sur une variable ajoute sa valeur actuelle et un horodatage dans un panneau, donc la fonctionnalité de lecture des valeurs/expressions existe bien dans l’UI, mais l’implémentation côté infobulle semble cassée
    Avec un peu de finition, ça pourrait être utile, mais parmi les front-ends que j’ai essayés jusqu’ici, celui que j’ai le moins détesté est Gede. Son UI est simple et intuitive, et même s’il n’a pas énormément de fonctionnalités, celles qui sont exposées ont tendance à bien fonctionner sans bug : https://gede.dexar.se/

    • Je suis l’auteur de Seergdb. J’aimerais que tu détailles le problème de configuration de la police de l’éditeur ; dans mes tests, cela semble fonctionner
      Pour enregistrer la configuration de façon permanente, il faut faire « Save Configuration... ». Je vais aussi tester l’affichage au survol des valeurs de variables ; ce serait bien de laisser les bugs ou demandes de fonctionnalités dans les issues GitHub
    • Comme je n’ai pas envie de gérer aussi des bugs dans l’outil de débogage pendant que je cherche des bugs dans mon code, je note Gede pour la prochaine fois où j’aurai besoin de déboguer

  • GDB dispose aussi, étonnamment, d’une interface utilisateur texte (TUI) intégrée assez facile à utiliser. Elle prend même en charge les interactions à la souris : https://sourceware.org/gdb/current/onlinedocs/gdb.html/TUI.h...

    • Personnellement, je préfère la ligne de commande à la TUI, mais on peut mettre ceci dans .gdbinit
      tui new-layout default regs 1 {-horizontal src 1 asm 1} 2 status 0 cmd 1
      tui layout default
      tui enable
    • La combinaison Neovim + nvim-dap + nvim-dap-ui + gdb était bien meilleure que ça
    • Malheureusement, cela ne fonctionne que si GDB a été compilé avec la prise en charge de la TUI

  • Après avoir essayé plusieurs front-ends pour GDB, je trouve que la TUI est ce qu’il y a de mieux. Quand le programme écrit de la sortie et casse l’interface, il suffit de connaître Ctrl + L pour la redessiner
    Dans $XDG_CONFIG_HOME/gdb/gdbinit, je ne mets que ceci
    layout src
    set confirm off

    • Pour l’invite en couleur, j’aime utiliser ceci
      set prompt \001\033[01;36m\002(gdb)\001\033[0m\002
      Et j’enregistre l’historique comme ceci
      set history save on
      set history size 500000
      set history filename ~/.cache/gdb/history
    • J’ai beaucoup utilisé gdb-dashboard et je le recommande. C’est similaire à la TUI, mais on peut choisir bien plus finement les informations à afficher, et les couleurs rendent la sortie beaucoup plus lisible
      On peut aussi afficher le tableau de bord dans un autre terminal, ou le répartir sur plusieurs terminaux, ce qui permet de créer une meilleure disposition des fenêtres. À une époque, j’avais écrit un script pour générer automatiquement une disposition de terminaux avec tmux et les connecter à GDB ; ça demandait pas mal d’efforts, mais on pouvait obtenir un très bon layout
    • Ctrl + L est indispensable à connaître dans les interfaces de type TUI, y compris quand l’écran de Vim est corrompu. Après l’avoir appris, j’ai résolu quantité de « crashes » mystérieux
    • gef prend en charge tmux, donc la sortie du programme part dans un autre panneau tmux
    • Le front-end gud-gdb dans Emacs est assez pratique et facile à utiliser

  • Même lorsqu’on est connecté à Linux depuis Windows ou qu’on utilise WSL, on peut déboguer à distance des processus Linux avec WinDBG/VisualStudio

    • Il suffit que gdbserver tourne côté distant, non ?

  • C’est une UI Qt pour GDB
    À ma connaissance, il existe aussi gdbgui, une UI web pour GDB : https://www.gdbgui.com/
    C’est toujours une bonne chose qu’il y ait davantage d’activité autour des outils de débogage

    • J’aime le fait que GDB fonctionne dans Qt Creator sans configuration compliquée. On place quelques points d’arrêt, on appuie sur exécuter, et l’IDE s’occupe du reste
    • Pour ajouter un autre élément à la liste des GUI pour GDB, il y a aussi celle que j’ai créée : https://github.com/dzaima/grr
      Il lui manque encore pas mal de fonctionnalités qui peuvent être indispensables pour certains usages. C’est parce que ma façon de l’utiliser relève surtout du débogage au niveau assembleur, donc je n’avais pas besoin de beaucoup de fonctionnalités sophistiquées
    • Il y a aussi DDD. C’est un front-end Motif
    • VS Code possède aussi un front-end GDB correct, particulièrement pratique pour déboguer des microcontrôleurs embarqués
    • Puisqu’on parle de débogueurs web, j’ai récemment créé un projet similaire axé sur le débogage d’assembleur x86-64 : https://github.com/robalb/x86-64-playground

  • Il y avait déjà eu une discussion de taille moyenne il y a 2 ans : https://news.ycombinator.com/item?id=33044885

  • Si vous utilisez Emacs, GUD est une intégration GDB plutôt excellente

    • Depuis l’arrivée de LSP, Emacs me semble meilleur que tout le reste. Aucune raison de partir. Surtout depuis qu’il est devenu plus rapide avec la compilation native
      Aucune raison de continuer à essayer le nouvel éditeur du mois parce qu’il a ajouté quelques fonctionnalités gadget. Il suffit d’ajouter un plugin à Emacs pour obtenir la même chose, tout en gardant le reste exactement comme je l’aime
      Je me suis vraiment mis au code à l’époque d’Atom, et j’ai été assez déçu qu’Atom disparaisse pour laisser place à VS Code. VS Code est bien, mais il ne suit pas la même philosophie qu’Atom
      Depuis que j’ai appris Emacs il y a environ 4 ans, aucun nouvel outil n’a réussi à me convaincre que « c’est une vieille technologie, il faut passer à autre chose ». Digression sortie de nulle part, mais je suis vraiment reconnaissant qu’Emacs continue de survivre
    • Je préfère M-x gdb, la GDB Graphical Interface d’Emacs, à l’intégration de base via GUD, M-x gud-gdb
      Récemment, j’ai dû repasser à GUD pour lancer lldb, et les fenêtres dédiées montrant les points d’arrêt, les threads, la pile courante, etc. m’ont manqué
      Le bon côté de GUD, c’est que l’interface reste cohérente quel que soit le débogueur. Ainsi, quand on passe du débogage de Python avec pdb au débogage de C++ avec lldb, on n’a pas besoin de réapprendre les raccourcis clavier
      https://www.gnu.org/software/emacs/manual/html_node/emacs/GD...
      https://www.gnu.org/software/emacs/manual/html_node/emacs/St...
    • dape(https://github.com/svaante/dape#) est une bonne option pour les langages qui disposent d’un débogueur implémentant le Debug Adapter Protocol
      En l’utilisant avec debugpy, je n’utilise plus M-x pdb, et l’UI est aussi très proche de M-x gdb
    • lsp-mode + dap-mode fonctionne bien aussi, mais il faut mettre un peu les mains dans le fichier launch.json

  • Sympa. Ça me rappelle DDD, qui m’avait semblé magique la première fois que je l’ai vu. Je suis surpris que DDD soit encore maintenu
    https://en.wikipedia.org/wiki/Data_Display_Debugger
    https://www.gnu.org/software/ddd/

    • J’ai appris DDD à l’université il y a 20 ans, et même à l’époque il me semblait déjà rustique. Aujourd’hui, je suis beaucoup plus indulgent, mais Motif reste toujours désagréable à l’œil
      À en juger par des années de discussions, DDD a paradoxalement été un excellent outil d’anti-marketing, poussant les développeurs vers l’UI de débogage intégrée de leur IDE préféré. DDD lui-même est certes très puissant, mais même « l’utilité prime sur l’esthétique » a ses limites
    • Bien sûr que DDD est maintenu. J’ai écrit ici sur ses fonctionnalités : https://begriffs.com/posts/2022-07-17-debugging-gdb-ddd.html
      Après la publication de l’article, les mainteneurs ont corrigé les problèmes que j’avais signalés, si bien qu’il n’y a désormais plus besoin de beaucoup de contournements. 3.4.0 et 3.4.1 sont des versions assez importantes
    • J’aime le fait que DDD intègre diverses visualisations graphiques. En particulier, j’ai toujours trouvé excellente la fonction de visualisation des structures de données
      Il y avait autrefois un projet de portage vers GTK3, mais il semble avoir disparu. Cela dit, je suis content que le projet principal continue
    • Ça me rappelle Insight, mon frontend GDB préféré, qui fonctionnait bien sous Windows à l’époque de cygwin. Malheureusement, il n’est clairement plus maintenu : https://sourceware.org/insight/screenshots.php
      Cela dit, il semble que quelqu’un l’ait déplacé sur GitHub, l’ait relancé et ait fait un peu de travail dessus : https://github.com/antony-jr/insight
    • DDD est excellent. Je l’utilise encore, mais je suis un fossile
      Je cherchais quelque chose de similaire à dbxtool, que j’utilisais sur d’anciennes machines Sun Microsystems, et je suis tombé sur DDD. Les gens d’aujourd’hui sont plutôt gâtés avec des choses comme le débogage au niveau source

  • Le projet GNU et RMS semblent souvent moqués comme des mèmes, mais GDB est un outil puissant. Je ne l’ai manipulé directement qu’un peu, mais il semble avoir eu un impact énorme sur le travail des développeurs pendant des années

    • Par pure curiosité, pourquoi GNU est-il moqué ?

  • Il y a plus de 10 ans, quand je faisais du C++ sous Linux, j’utilisais Qt Creator, qui avait un débogueur intégré. C’était un frontend GDB, il fonctionnait très bien, et pour C++ et Qt je ne voyais aucune raison d’utiliser autre chose