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.
[^] # Re: À rebours?
Posté par djano . En réponse à la dépêche GDB 7.0 et le déverminage concurrentiel à rebours. Évalué à 3.
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.