ddbg_gdb with emacs

[Jascha Wetzel]

i'll have issue1 fixed in the next release. also "print" and "clear"
will be added.

> ISSUE 2:
> [...]
> "  source C:/tmp/mingwdbg/hello.c:22:"

what do you mean by that "source" there?

> (concat "\032\032\\(.:?[^" ":" "\n]*\\)" ":" "\\([0-9]*\\)" ":" ".*\n"))

what are the double backslashes doing there? aren't the brackets
supposed to group the matches? if it's just an implementation detail and
the regexp is actually
\032\032(.:?[^:\n]*):([0-9]*):.*\n
then the lines ddbg outputs should match.
codeblocks uses
\032\032([A-Za-z]:)([^:]+):([0-9]+):[0-9]+:[begmidl]+:(0x[0-9A-z]+)


Bill Baxter wrote:
> 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