GDB 7.0 et le déverminage concurrentiel à rebours

Posté par (page perso) . Modéré par tuiu pol.
Tags :
30
10
oct.
2009
GNU
Ce mardi 6 octobre a été annoncée la disponibilité de la version 7.0 du debugger GNU. Outre l'ajout de la gestion native des environnements x86/x86_64 Darwin et x86_64 MinGW, du scripting Python et d'un certain nombre de correction de bugs, cette version introduit le support du déverminage à rebours, du « non-stop debugging » et du debugging multi-processus. L'idée du déverminage à rebours est simplement de permettre les opérations de « stepping » à l'envers et donc d'exécuter le programme à l'envers. Cela est particulièrement utile pour remonter aisément à la source d'une erreur qui peut avoir été causée par un enchaînement d'événements qui ne sont pas forcément évidents à tracer si on ne peut qu'avancer dans le programme. Le principe n'est pas récent puisqu'il a été présenté par Bil Lewis en 2003 avec l'Omniscient Debugger (ODB) pour Java et que le projet GDB a commencé son implantation en 2006. L'intégration de cette fonctionnalité dans une version stable de GDB devrait faciliter la vie de bon nombre de développeurs.

Une autre nouvelle fonctionnalité qui ravira les programmeurs d'applications multi-threads est le « non-stop debugging » qui permet d'examiner l'état d'un thread sans interrompre l'exécution des autres files d'exécutions. Quant à ceux qui préfèrent avoir un thread par processus, GDB gère maintenant les applications multi-processus.

Il est à noter que ces fonctionnalités semblent être principalement le fait de Marc Khouzam et Francois Chouinard d'Ericsson qui ont également modifié le greffon Eclipse CDT en conséquence.
  • # hein ?

    Posté par (page perso) . Évalué à -6.

    déverminage à rebours ?

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: hein ?

      Posté par (page perso) . Évalué à 8.

      c'est expliqué dedans /o\

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: hein ?

        Posté par (page perso) . Évalué à -1.

        Ce qui manque surtout, c'est mentionner que déverminage = debug.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: hein ?

        Posté par . Évalué à 3.

        Déverminage == debugging ?

        Parce que bon... il faut choisir, soit on utilise le français et on s'y tient en explicitant les termes, soit on utilise le mot (anglais certes) utilisé par la quasi totalité des développeurs français, mais on évite de mélanger les deux. (ou alors, on utilise les guillemets partout autour d'une des deux locutions...)

        Cela dit, j'aime bien ce mot ^^
        • [^] # Re: hein ?

          Posté par (page perso) . Évalué à 7.

          C'était surtout pour rendre le titre « intéressant » :) Après dans l'article j'ai utilisé debugging pour mitiger la répetition parce que je vois pas beaucoup de synonymes possibles. Mais il est vrai que les italiques ou guillemets auraient pu être utilisées de manière plus cohérente.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: hein ?

            Posté par . Évalué à 4.

            il y a aussi épépinage si tu veux faire du 100 % fr (et épépineur donc)
        • [^] # Re: hein ?

          Posté par (page perso) . Évalué à 7.

          Surtout qu'il me semblait que le terme en français était "débogage", GDB étant un "débogueur".

          Si on commence à avoir des francisations concurrentes, on n'a pas fini ;)
  • # À rebours?

    Posté par (page perso) . Évalué à 6.

    Comment ça marche à rebours? GDB se souvient de l'état de toutes les variables à chaque instruction? Ça ne prend pas trop de mémoire?


    1. a = scanf ("%d\n");
    2. printf ("a=%d\n", a);
    3. a = scanf ("%d\n");
    4. printf ("a=%d\n", a);


    Imaginons un breakpoint sur 4. puis qu'on éxécute à revers jusqu'à 2.. Comment GDB peut-il savoir la valeur de la variable a?

    Ça marche aussi quand il y a des entrées/sorties? Comment on revient en arrière quand on débugge un serveur web et qu'on a écrit quelque chose sur la socket du browser? GDB téléphone au browser et lui dit "revient en arrière, s'il te plait?"
    • [^] # Re: À rebours?

      Posté par . Évalué à 3.

      meuh non tout le monde sait que le téléphone ne fonctionne avec TCP/IP.
      • [^] # Re: À rebours?

        Posté par . Évalué à 8.

        *pas

        désolé pour le bug mais je ne peux pas remonter dans le temps
    • [^] # Re: À rebours?

      Posté par . Évalué à 2.

      Pas forcement toutes les variables, il peut faire des snapshots à intervalle régulier. Pour les entrées sorties, suffit juste de snapshotter juste après. Et il y a des moyens d'être plus intelligent.
      • [^] # Re: À rebours?

        Posté par (page perso) . Évalué à 4.

        Je n'y connais rien du tout mais à priori c'est plus puissant que des simples snapshots à intervalle régulier.
        Regarde ce commentaire : http://lwn.net/Articles/356151/

        "You're thinking of checkpoint/restart. This is completely different.
        The present "reverse debugging" feature set allows you to do reverse-step, reverse-next, reverse-continue etc., running backward to any breakpoint or watchpoint, or just stepping backward by a single instruction if you choose. You're not restricted to stopping only at previously designated checkpoints
        ".
        • [^] # Re: À rebours?

          Posté par (page perso) . Évalué à 10.

          Je modère l'entousiasme en indiquant que ce déboggage à rebours ne fonctionne que pour le code qui vient d'être exécuté pas à pas. On ne peut pas poser un point d'arrêt, puis magiquement remonter le temps. Ce serait trop beau :-)

          Ca existe depuis des années. Je me souviens l'avoir eu dans les années 90 avec Turbo Debugger de Borland en 1991 ou 1992, ainsi que dans le débogueur de Watcom C que j'avais avec OS/2 Warp mi-1995.
          • [^] # Re: À rebours?

            Posté par (page perso) . Évalué à 5.

            Effectivement c'est pas magique et ça sait pas tout défaire mais il n'est quand même pas nécessaire de single-stepper explicitement. Il suffit de passer en mode « target record » et on peut reserve debugger à loisir ou presque à partir de ce moment.

            Par contre il me semble que ODB garde bien une trace de tout l'état du programme à chaque instruction (comme s'il était en mode « target record » en permanence donc).

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: À rebours?

              Posté par (page perso) . Évalué à 8.

              single-stepper : avancer pas à pas

              Quand il y a des mots français qui signifient exactement la même chose, on peut les employer !
            • [^] # Re: À rebours?

              Posté par . Évalué à 2.

              Je ne pense pas qu'il stocke tout l'état du programme à chaque instruction mais simplement le minimum d'informations pour pouvoir revenir en arrière (en gros l'adresse de l'instruction d'où il vient qui n'est pas forcement l'adresse précédente si on a fait un saut ; et l'état des registres et des mémoires qui ont été modifiées ou écrasées par l'instruction).

              On stocke quelques octets par instruction exécutée, ce qui peut quand même faire beaucoup ; cela doit souvent ralentir l'exécution d'un bon facteur 10) mais je pense que le jeu en vaut vraiment la chandelle.
              • [^] # Re: À rebours?

                Posté par (page perso) . Évalué à 3.

                Quand je parle de stocker tout l'état à chaque instruction je pense effectivement plutôt à stocker les différences entre les états entre deux instructions. Une peu à la façon dont les vidéo sont compressées : on a une image de base et l'image suivante, c'est la même avec un delta (c'est sans doute super simplifié, j'y connais rien en encodage vidéo).

                C'est juste qu'au final ça revient au même qu'à stocker tout l'état à chaque instruction, la manière dont c'est « compressé » ne sont que des « détails » d'optimisation.

                pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: À rebours?

            Posté par (page perso) . Évalué à 2.

            Argh ! Et moi qui croyais qu'on y était enfin, snif !

            Surtout que c'est quand même pas impossible de faire ça même après un point d'arrêt, si le code compilé est prévu pour être réversible (moyennant l'utilisation d'une option spéciale du compilo), le programme gardant en mémoire les résultats intermédiaires s'ils sont nécessaires pour assurer le reverse debug.
        • [^] # Re: À rebours?

          Posté par . Évalué à 4.

          Ce que je disait c'était que les deux fonctionnalités pouvaient être en gros équivalentes. Si j'ai un snapshot à N et que je suis N+200000 instructions plus loins, si j'ai assez d'information* sur ce qui se passe entre N et N+200000, je peux repartir de N et éxecuter 199999 instructions pour faire mon step-back.

          * Avoir assez d'information, c'est par exemple retenir ce que les E/S ont produit.
          • [^] # Re: À rebours?

            Posté par (page perso) . Évalué à 1.

            Sauf si tu as des éléments externes que ton programme va relire (état matériel, horloge...).
            Mais pour tout ce qui est purement calculatoire, oui.
    • [^] # Re: À rebours?

      Posté par . Évalué à 3.

      J'avais lu la proposition d'implémentation du projet ajoutant le reverse debugging à GCC. Autant que je me souvienne, le debugger faisait effectivement des snapshots du programme à intervalle régulier, et il se rappelait également autant que possible des entrées-sorties (entrée standard, socket TCP/IP, interrupts, ...). Lorsque l'utilisateur faisait un pas en arrière, le programme était exécuté à nouveau depuis le snapshot jusqu'au point d'arrêt.
      C'était l'approche choisie.

      Quand à lui, l'omniscient debugger pour Java enregistre des informations lors de l'exécution du programme. Et lorsque l'on fait un pas en arrière, il consulte juste ce qui avait été enregistré, et utilise juste cette mémoire pour revenir en arrière. Il était possible de paramétrer la quantité de données que le debugger peut utiliser pour se rappeler les états précédents.

      Je pense que l'approche 1 convient à un programme bas niveau alors que l'approche 2 convient à un programme plus haut niveau. Le programme bas niveau doit se rappeler plus de choses.
  • # reverse

    Posté par . Évalué à 5.

    Cela est particulièrement utile pour remonter aisément à la source d'une erreur qui peut avoir été causée par un enchaînement d'événements qui ne sont pas forcément évidents à tracer si on ne peut qu'avancer dans le programme.

    Et aussi pour faire du reverse engineering sur des softs proprios dont le code a été pourri de code inutile.
  • # gdb à travers irc

    Posté par . Évalué à 8.

    La possibilité de scripter gdb avec python permet des choses fantaisistes pour certains mais pouvant être très utiles pour d'autres comme le fait de pouvoir débogguer par irc sur un gdb à distance.
    Un petit plugin a été écrit par un développeur gnome, que l'on peut trouver sur son blog :
    http://blogs.gnome.org/alexl/2009/10/09/gdb-over-irc/

    Pour avoir fait ce dur processus de déboggage par irc, « à l'ancienne », je ne peux que saluer l'initiative.
  • # Si même les nobles s'y mettent...

    Posté par . Évalué à 4.

    "Francois Chouinard d'Ericsson"
    Un nom à particule qui développe un déboggueur ?!?




    ====>[]
    • [^] # Re: Si même les nobles s'y mettent...

      Posté par . Évalué à 5.

      Sûr. Il aurait fallu dire : « François Chouinard de chez Ericsson en face »…

      (En passant, la particule n’est pas synonyme de noblesse et inversement, monsieur _2_b.)
    • [^] # Re: Si même les nobles s'y mettent...

      Posté par (page perso) . Évalué à 2.

      Y a bien un «Sir Timothy John Berners-Lee» qui à pondu un truc appelé web…
      • [^] # Re: Si même les nobles s'y mettent...

        Posté par . Évalué à 7.

        Sauf qu'il est devenu "Sir" pour cette raison, justement. Il n'aurait rien pondu du tout, ça serait "Timothy John Berners-Lee" tout court, mouleur sur DLFP, le document qu'on va télécharger en FTP (ben ouais, sans Web, hein..).

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Si même les nobles s'y mettent...

          Posté par . Évalué à 2.

          Anéfé :
          "Le 16 juillet 2004, il est anobli par la reine d'Angleterre Élizabeth II lors d'une cérémonie d'investiture à Londres où il reçoit le titre de chevalier commandeur de l'Ordre de l'Empire britannique. Ce titre, classé deuxième dans le classement des décorations, lui est attribué en reconnaissance de services rendus pour « le développement global d'Internet »."
          (source : Tim_Berners-Lee)

          Mais pour pas faire de jaloux :
          "Le 2 mars 2005, Bill Gates est anobli par la reine Élisabeth II du Royaume-Uni au grade de chevalier d’honneur de l’ordre de l'Empire britannique pour sa contribution aux entreprises britanniques et pour les efforts qu'il déploie à combattre la pauvreté dans le monde. Toutefois, n'étant pas citoyen d'un pays du Commonwealth, il ne peut préfixer son nom du titre Sir. Il peut cependant ajouter les lettres KBE (Knight of British Empire/Chevalier de l'Empire britannique) à la suite de son nom."
          (source Bill_Gates)
    • [^] # Re: Si même les nobles s'y mettent...

      Posté par . Évalué à 4.

      « Un nom à particule qui développe un déboggueur ?!? »

      Ben et pourquoi pas ? Je vois pas le rapport.
  • # Pretty printing

    Posté par . Évalué à 6.

    Il n'en est pas fait mention dans le dépêche, mais avec le scripting python arrive une fonctionnalité attendue depuis longtemps : le pretty-printing [1]. Cela permet de définir comment afficher une variable suivant son type. Jusqu'ici, gdb affichait tous les membres de la classe récursivement. On peut maintenant définir une classe qui spécifie comment afficher un objet d'un type particulier. Par exemple au lieu d'afficher les objets de type std::string comme ceci (exemple tiré de la doc) :
    (gdb) print s
    $1 = {
    static npos = 4294967295,
    _M_dataplus = {
    <std::allocator> = {
    <__gnu_cxx::new_allocator> = {<No data fields>}, <No data fields>},
    members of std::basic_string<char, std::char_traits, std::allocator >::_Alloc_hider:
    _M_p = 0x804a014 "abcd"
    }
    }


    On aura :
    (gdb) print s
    $2 = "abcd"


    Je pense qu'on va rapidement avoir des scripts python pour afficher de façon plaisante les éléments la STL ou de Qt.

    [1]. http://sourceware.org/gdb/current/onlinedocs/gdb_24.html#SEC(...)
    • [^] # Re: Pretty printing

      Posté par . Évalué à 2.

      Je pense qu'on va rapidement avoir des scripts python pour afficher de façon plaisante les éléments la STL ou de Qt.

      J'aurai dû vérifier avant mais dans le trunk de gcc[1], on trouve déjà des choses pour la STL. Exemple (elem est un std::string et vect est un vecteur de std::string) :
      (gdb) print elem
      $1 = "bonjour"
      (gdb) print vect
      $2 = std::vector of length 0, capacity 0
      (gdb) next
      (gdb) print vect
      $3 = std::vector of length 1, capacity 1 = {"bonjour"}
      (gdb) next
      (gdb) print
      $4 = std::vector of length 2, capacity 2 = {"bonjour", "toto"}


      [1].http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/python/lib(...)

Suivre le flux des commentaires

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