ddbg_gdb with emacs

[Bill Baxter]

I was trying to see if maybe ddbg_gdb already worked with emacs and if 
not what it would take to make it work.

The way emacs works with gdb is that you type the gdb command yourself 
(though it gives you a default)

Emacs uses this command by default, though it's easy to change:
    gdb --annotate=3 [progname]

Here's how it's documented:
"""
gdb is an interactive compiled Lisp function in `gud.el'.
It is bound to <menu-bar> <tools> <gdb>.
(gdb COMMAND-LINE)

Run gdb on program FILE in buffer *gud-FILE*.
The directory containing FILE becomes the initial working
directory and source-file directory for your debugger.  By
default this command starts GDB using a graphical interface.  See
`gdba' for more information.

To run GDB in text command mode, replace the GDB "--annotate=3"
option with "--fullname" either in the minibuffer for the
current Emacs session, or the custom variable
`gud-gdb-command-name' for all future sessions.  You need to use
text command mode to debug multiple programs within one Emacs
session.
"""

This looks to be the subset of commands the gdb/emacs interface uses if 
you can grok a little lisp (even if you don't it's pretty obvious I think):

"""
   (gud-def gud-break  "break %f:%l"  "\C-b" "Set breakpoint at current 
line.")
   (gud-def gud-tbreak "tbreak %f:%l" "\C-t"
	   "Set temporary breakpoint at current line.")
   (gud-def gud-remove "clear %f:%l" "\C-d" "Remove breakpoint at 
current line")
   (gud-def gud-step   "step %p"     "\C-s" "Step one source line with 
display.")
   (gud-def gud-stepi  "stepi %p"    "\C-i" "Step one instruction with 
display.")
   (gud-def gud-next   "next %p"     "\C-n" "Step one line (skip 
functions).")
   (gud-def gud-nexti  "nexti %p" nil   "Step one instruction (skip 
functions).")
   (gud-def gud-cont   "cont"     "\C-r" "Continue with display.")
   (gud-def gud-finish "finish"   "\C-f" "Finish executing current 
function.")
   (gud-def gud-jump
	   (progn (gud-call "tbreak %f:%l") (gud-call "jump %f:%l"))
	   "\C-j" "Set execution address to current line.")

   (gud-def gud-up     "up %p"     "<" "Up N stack frames (numeric arg).")
   (gud-def gud-down   "down %p"   ">" "Down N stack frames (numeric arg).")
   (gud-def gud-print  "print %e"  "\C-p" "Evaluate C expression at point.")
   (gud-def gud-pstar  "print* %e" nil
	   "Evaluate C dereferenced pointer expression at point.")
   (gud-def gud-until  "until %l" "\C-u" "Continue to current line.")
   (gud-def gud-run    "run"	 nil    "Run the program.")

"""

Here's a link to the full gud.el source that implements gdb support.
http://tinyurl.com/2c2evb

ISSUE 1:
It seems that ddbg_gdb currently requires the full path to the exe to be 
specified.  Since I have to type this myself in emacs, it would be nice 
if it would look relative to the current directory too.  Not a 
show-stopper, though.

ISSUE 2:
Emacs uses the console output from gdb to determine where it is when 
stopped at a breakpoint.  And specifically it seems to require the 
message format --annotate=3.

This is the main regexp it uses to find the useful lines:

(defvar gud-gdb-marker-regexp
   ;; This used to use path-separator instead of ":";
   ;; however, we found that on both Windows 32 and MSDOS
   ;; a colon is correct here.
   (concat "\032\032\\(.:?[^" ":" "\n]*\\)" ":"
	  "\\([0-9]*\\)" ":" ".*\n"))

There's some other mojo going on in the function called 
gud-gdb-marker-filter, but it looks like just being anal about always 
printing lines like:

"  source C:/tmp/mingwdbg/hello.c:22:496:beg:0x401322"

after every operation will be enough to make it work. And as you can see 
that regexp only cares about this much of it:

"  source C:/tmp/mingwdbg/hello.c:22:"


--bb