Utiliser colout pour colorier tout ce qu'affiche GDB

Posté par  (site web personnel, Mastodon) . Édité par Benoît Sibaud. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
34
17
oct.
2014
Ligne de commande

Je sais ce que vous pensez : vous avez beau essayer d'utiliser des interfaces graphiques avec le débogueur GDB (GNU Project Debugger), vous finissez toujours par revenir à la bonne vieille ligne de commande, qui seule vous permet de ressentir une flamboyante puissance et une incandescente rapidité d'action. Dans le même temps, vous aimeriez bien que certaines informations importantes soient agrémentées d'un rouge pétant qui saute aux yeux. Comme je vous comprends. Fort heureusement, GDB est un logiciel complètement hackable, ce qui va me permettre d'exaucer vos vœux les plus ardents.

Il est en effet possible d'attacher des hooks à chaque commande, et d'y appeler des commandes shell. Afin d'ajouter notre touche de carmin, il suffit donc de récupérer la sortie de la commande et de la faire passer dans un colorisateur écarlate. C'est possible, car GDB permet de logguer tout ce qui se passe et qu'Unix a eu la bonne idée d'inventer les pipes nommés.
Pour ajouter la touche de pourpre, un colorisateur capable de gérer facilement des expressions régulières est nécessaire, je vous suggère colout.

La suite de la dépêche vous donnera un exemple de fichier de configuration à utiliser pour ajouter votre touche d'andrinople à votre propre système.

Équipé de tous ces outils libres ultra-cools, il suffit d'éditer votre .gdbinit préféré :

# Créer le pipe de communication.
shell test -e /tmp/coloutPipe && rm /tmp/coloutPipe
shell mkfifo /tmp/coloutPipe

# Activer la redirection (à appeler APRÈS votre commande)...
define logging_on
  set logging redirect on.
  set logging on /tmp/coloutPipe
end
# la désactiver.
define logging_off
  set logging off
  set logging redirect off
  # Voilà la partie foireuse du hack : pour éviter que le prompt ne s'affiche avant la sortie, il faut le faire attendre...
  shell sleep 0.4s
end

# Premier exemple : coloration syntaxique complète du code source.
define hook-list
    shell cat /tmp/coloutPipe | colout --all --source Cpp &
    logging_on
end
define hookpost-list
    logging_off
end

# Deuxième exemple : coloration de la pile.
define hook-backtrace
    # Regexp pour [path]file[.ext]: (.*/)?(?:$|(.+?)(?:(\.[^.]*)|))
    shell cat /tmp/coloutPipe | colout "^(#)([0-9]+)\s+(0x\S+ )*(in )*(\S+) (\(.*\)) at (.*/)?(?:$|(.+?)(?:(\.[^.]*)|)):([0-9]+)" red,red,blue,none,green,cpp,none,white,white,yellow normal,bold,normal,normal,bold,normal,normal,bold,bold,bold &
    logging_on
end
define hookpost-backtrace
    logging_off
end

Vous noterez que dans ce dernier exemple, le numéro de frame est coloré d'un vermeil¹ du plus bel effet.

¹ C'est quand même dingue le nombre de synonymes de « rouge » dans la langue française, non ?

Aller plus loin

  • # /tmp, vraiment ?

    Posté par  (site web personnel) . Évalué à 3.

    Réaction primaire : Cela ne coûte pas très cher d'utiliser ~/tmp au lieu de /tmp et cela peut rapporter gros… (Ne serait-ce que pour éviter de marcher sur les orteils du voisin, ou bien pour éviter les problèmes de sécurité triviaux.)

    Debian Consultant @ DEBAMAX

    • [^] # Re: /tmp, vraiment ?

      Posté par  . Évalué à 4.

      $XDG_RUNTIME_DIR n'est pas mieux pour avoir un dossier temporaire personnel ? Il me semble que c'est son rôle.

      • [^] # Re: /tmp, vraiment ?

        Posté par  (site web personnel) . Évalué à 3.

        Utiliser cette variable (ou TMPDIR à défaut) dans un fichier de configuration peut être compliqué, d'où ma proposition. Je pense notamment aux paramètres ControlPath/ControlMaster de ssh_config.

        Comme le note JoeltheLion dans sa réponse, on peut aussi passer par une création de répertoire temporaire sécurisée. Cela est relativement peu pratique pour les fois où l'on a à créer un fichier temporaire pour stocker un résultat intermédiaire, c'est pourquoi je proposais de s'habituer les doigts à taper ~/tmp au lieu de /tmp.

        Debian Consultant @ DEBAMAX

    • [^] # Re: /tmp, vraiment ?

      Posté par  (site web personnel) . Évalué à 7.

      Il me semble que la solution correcte est de créer un répertoire temporaire avec les bonnes permissions dans /tmp, avec mktemp -d en shell par exemple.

    • [^] # Re: /tmp, vraiment ?

      Posté par  . Évalué à 3.

      Réaction primaire: le problème, c'est que le ~/tmp n'est pas vidé automatiquement au boot :)

      • [^] # Re: /tmp, vraiment ?

        Posté par  (site web personnel) . Évalué à 1.

        tmpreaper est ton ami.

        Cela évite de dépendre d'un reboot (choisi ou subi) pour supprimer les fichiers qui traînent dans /tmp (depuis trop longtemps ou sur lesquels on était en train de travailler quand oh-zut-un-reboot).

        Debian Consultant @ DEBAMAX

        • [^] # Re: /tmp, vraiment ?

          Posté par  . Évalué à 2.

          Ça à l'air bien utile cet outil. Merci!

          • [^] # Re: /tmp, vraiment ?

            Posté par  . Évalué à 1.

            Selon la distribution, il peut ne pas être dans les dépôts. Mais il y a tmpwatch qui est équivalent.
            Sinon, un bon vieux find des familles fait le boulot aussi.

            • [^] # Re: /tmp, vraiment ?

              Posté par  . Évalué à -1.

              Sinon, un bon vieux find des familles fait le boulot aussi.

              Ouai mais tu vois, ça marche plus parce que la famille est morte avec l'adoption du mariage pour tous !

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # GDB

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Qu'est GDB? Grand Doigt Brandit ?

    • [^] # Re: GDB

      Posté par  . Évalué à 4.

      Dans mon cas c'est plutôt Gros Doigts Boudinés quand il s'agit de l'utiliser.
      C'est un debugger C C++ (et d'autres, mais je me cantonne à ces langages), qui permet entre autres d'analyser l'exécution d'un binaire, ou encore de chercher les causes d'un plantage en analysant le coredump.
      http://www.gnu.org/software/gdb/

    • [^] # Re: GDB

      Posté par  (site web personnel) . Évalué à 3.

      Corrigé, merci.

      • [^] # Re: GDB

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Tant qu'on y est : les tags sont en vrac et il faut corriger « apès » par « après ».

        • [^] # Re: GDB

          Posté par  (site web personnel) . Évalué à 4. Dernière modification le 17 octobre 2014 à 10:44.

          les tags sont en vrac

          Je ne comprends pas la demande (mais j'ai corrigé la typo).

          Edit: ok d'après l'entrée de suivi je suppose qu'un ou plusieurs tags ont été masqués depuis.

  • # cgdb

    Posté par  (site web personnel) . Évalué à 3.

    personnellement pour avoir de jolie couleur, j'utilise cgdb , qui est tout autant dans le terminal.

    Apres j'imagine que ta technique permet d'avoir plus de controle sur les couleurs (d'ailleurs je me demande si les deux ne sont pas utilisables conjointement)

    • [^] # Re: cgdb

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      J'étais utilisateur de cgdb moi aussi. Mais il ne propose que la coloration syntaxique de la fenêtre de code (permanente), pas la coloration des sorties des commandes (le hack présenté faisant les deux).

      Par contre, cgdb ne semble pas gérer les couleurs dans son interface curses, j'ai essayé un prompt coloré et les caractères d'échappement ne sont pas interprétés.

      Du coup, j'ai abandonné cgdb au profit d'un gdb standard où j'ai ajouté la commande list à chaque arrêt (ce qui est du coup très similaire à la fenêtre de code permanente).

  • # bonne idée

    Posté par  (site web personnel) . Évalué à 3.

    bonne idée que tu as eu là, je teste dès lundi !

    Je sais ce que vous pensez : vous avez beau essayer d'utiliser … le débogueur GDB

    en lisant ça, je m'attendais … au contraire ! vous avez essayé, mais vous n'avez pas réussi ! c'est souvent le cas. Ou alors le debogueur dans Eclipse, oui, mais en ligne de commande, ça fait trop peur !

    Ceci dit, c'est une bonne technique que tu proposes, l'interface CLI est super intuitive et pratique quand on a l'habitude, mais elle est un peu austère aussi. Alors mettre de la couleur dans tout ça ne peut pas faire de mal, surtout que ton idée est 100% transparente à l'utilisation.

    En jouant avec le prompt hook en python, on peut aussi afficher dans le prompt le nom du fichier et la ligne courante.

    • [^] # Re: bonne idée

      Posté par  . Évalué à 2.

      En fait, je pense qu'il fait référence à ddd ici. Par exemple. Et cette IHM est proprement… inutilisable, selon ma très personnelle opinion.

      • [^] # Re: bonne idée

        Posté par  (site web personnel) . Évalué à 1.

        nan mais je ne pas être plus d'accord, DDD ou n'importe quelle autre interface. DDD faut dire aussi à sa décharge qu'il est ante-diluvien, d'après son SVN la 1ere révision a 19 ans !

        Remarque GDB est aussi vieux que moi, 1986, mais il est toujours en développement actif, par Red Hat et Mentors Graphic (ex Code Sourcery).

      • [^] # Re: bonne idée

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        J'ai essayé ddd, insight, nemiver, kdevelop, eclipse et cgdb.
        Et au final je préfère gdb tout seul. Il faut passer par la case apprentissage, mais on est gagnant au final (comme souvent avec les outils en ligne de commande).

  • # Non à la couleur dans le terminal !

    Posté par  (site web personnel) . Évalué à 7.

    Puisqu'on est dans la couleur, je ne résiste pas à l'envie de partager ma découverte du jour : un petit caviar de mauvaise foie issue du ~/.bashrc de ubuntu/debian par défaut.

    # uncomment for a colored prompt, if the terminal has the capability; turned
    # off by default to not distract the user: the focus in a terminal window
    # should be on the output of commands, not on the prompt
    #force_color_prompt=yes

    En gros si tu utilises la couleur dans ton prompt, c'est que t'es un n00b frivole !
    Mince, moi qui croyait que ça servait à repérer le début d'une commande instantanément quand on navigue dans son historique, à avoir une aide visuelle pour savoir si on est en local ou sur une autre machine en ssh ou encore si on est sur une console root etc…

    C'est grâce à ce genre de foutage de gueule qu'on s'est saigné les yeux pendant des décennies sur les sorties de gcc (miam les erreurs de templates C++ hyper-verbeuses en monochrome !) jusqu'à ce que clang arrive et que la vindicte populaire force gcc à s'aligner dessus.

    • [^] # Re: Non à la couleur dans le terminal !

      Posté par  . Évalué à 1. Dernière modification le 17 octobre 2014 à 15:15.

      Oui, je me suis toujours demandé quel était le sens de ce… disons… commentaire.

      J'imagine qu'en fait, c'est lié au fait que certaines consoles peuvent ne pas être super contente de devoir afficher de la couleur, ou interpréter les caractères spéciaux bizarrement. Mais pourquoi ne pas le dire directement dans ce cas? Ça reste un mystère pour moi.

      Du coup sur chaque bécane faut se taper l'édition à la mano de ces p***** de scripts dans le tc… d'un autre côté, je me dis que c'est un bon moyen pour repérer si l'utilisateur de la machine aime les lignes de commande ou pas :)

      Au passage, vu que tu découvres ce commentaire, il est envisageable que tu ne connaisses pas l'option -R de less. Très utile. Très, très utile (faudrait juste que je trouve une astuce simple pour colorer différemment les différentes regex de grep, comme ça je pourrai transformer les log en véritables arbres de nowel au taf :p).

  • # Marche presque

    Posté par  (site web personnel) . Évalué à 2.

    Avec une version de colout clonée depuis GitHub ce matin, j'ai une erreur qui m'empêche de voir la pile d'appel :

    Program received signal SIGABRT, Aborted.
0x00007ffff5e7abb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type.
(gdb) where
[colout] ERROR: unknown color: cpp
cat: erreur d'écriture: Relais brisé (pipe)

    Une idée pour résoudre ce petit souci ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.