gdb-like integration?

2007-02-27
2013-05-02
  • Hello everybody.
      I would like to see if anybody find this useful. I have used gdb (and joe, of course) for a while, and I think it would be awesome that joe supports some kind of integration with gdb, in a similar way it does with make (esc-C) or grep (esc-G).

    As gdb has an emacs-like mode (option -f), that print linenumbers in the same way that esc-C or esc-G expect, the only thing that now makes impssible to use joe for tracing gdb executions is the fact that you only can start browsing trhough files once the execution (of make, grep, or other program) is finished, and that its necessary to press [esc] + each time you want to go to the next line.

    So, does anybody think that it's possible to expect a future joe version, where the browsing through files could start before the command finishes, and that browsing could go from line to line while they are outputted from the command?

    Thanks,
      Rodrigo.

     
    • Derek Peschel
      Derek Peschel
      2007-03-04

      That's an interesting idea.  It would be much better than using gdb by itself, and if the keys were chosen carefully it might be easier to use than emacs's version of the same feature.

      However, you would have to implement more than just a line number parser.  Mainly you'd need a way to send commands to gdb, because you need to place breakpoints, start the program you're debugging, look at variables, and so on.  gdb is not a trace program -- it only prints line numbers when breakpoints are hit, and it only hits breakpoints when you create them.  So being able to send commands to gdb is essential.  (You might be thinking "why not change gdb to be a trace program so joe can ask for the next line without knowing how to send any other commands?"  That would be worse than using gdb without joe, because it would be phenomenally slow and boring and unforgiving of errors.)  Luckily joe's shell feature already lets you send commands to a program running in a joe window.  So you might have the gdb session showing in half the screen and the source files (gotten from the line number printouts) in the other half.

      By the way, when you start gdb with the -f flag, the line numbers have marker bytes before them.  That's necessary for exactly the reason you mentioned, that gdb is running (and printing other things) while it prints the line numbers.  I'm sure the modified shell mode could remove the marker bytes.  Then the current line number code would probably work.

      For a fancier design, you'd need keystrokes that sent commands to gdb.  Instead of going to the gdb window and typing "b main" and return, you would go to your source file and hit ESC b (or whatever) which would send the command to gdb.  In order to make those keystrokes worthwhile, they need to find which source file and line the cursor is on, and convert that to a format gdb reads.

      You may want to try out the emacs interface to see what it's like, and then invent some hypothetical commands for joe, and give them keystrokes.  That would give you a better idea of how joe needs to be changed.

      I should mention that I use joe -- really jstar -- because it does common jobs well, and is good at a few important things emacs is bad at.  I don't expect joe to be big and fancy like emacs.  So the debugger interface should match the spirit of joe, not the spirit of emacs.