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

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

Here's some additional info I've found.

You probably already realized this, but this output
"  C:/tmp/mingwdbg/hello.c:22:496:beg:0x401322"
is also generated with the --fullname, which you're already supporting (actually you're generating --fullname output whether or not the flag is supplied :-P)

So I'm not sure why it doesn't already work.  The only difference I can see is that you omit the filename.
"  :22:496:beg:0x401322"

and maybe emacs needs that filename there.

Can you try just adding the full filename to that output string?

That should enable emacs to at least display the current source line.


Unfortunately I discovered there's another file called gdb-ui.el that implements most of the other nifty features of the gdb mode, like showing breakpoints etc.  It is triggered by finding "\n  prompt" in the output after "(gdb)" which is something --annotate prints.

The extended processing relies pretty heavily on the specific format of --annotate=3 output.
Here's a url for gdb-ui.el for the record: http://tinyurl.com/25b6gw
Specifically the thing to look for is the function
  (defun gud-gdba-marker-filter ... )



--bb

Jascha Wetzel wrote:
> i'll have issue1 fixed in the next release. also "print" and "clear"
> will be added.

Great!

>> ISSUE 2:
>> [...]
>> "  source C:/tmp/mingwdbg/hello.c:22:"
> 
> what do you mean by that "source" there?

Sorry that's what gdb outputs when you use "--annotate" instead of "--fullname".  Only relevant if your going to parse --annotate output. For --fullname it's just
"  C:/tmp/mingwdbg/hello.c:22:"

>> (concat "\032\032\\(.:?[^" ":" "\n]*\\)" ":" "\\([0-9]*\\)" ":" ".*\n"))
> 
> what are the double backslashes doing there? 

That's an emacs-regex thing.  \( \) are group delimiters and ( ) are literal parentheses in emacs.

> 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.

Yeh, that's the regexp emacs uses for basic non-annotate mode.  Like I said in my next message it looks like it should be matching, so my guess is just that it doesn't know what to do with a missing filename.

> codeblocks uses
> \032\032([A-Za-z]:)([^:]+):([0-9]+):[0-9]+:[begmidl]+:(0x[0-9A-z]+)

Is that the only regex they use?  Because that doesn't look like it would match without the filename.  It also doesn't look like it would match MinGW gdb's output which is like:
"  C:/tmp/mingwdbg/hello.c:22:496:beg:0x401322"

Note "beg" vs "begmidl".


--
One more minor commandline usability nit:
ddbg_gdb doesn't work without an -args parameter.


-bb

Bill Baxter wrote:

>> codeblocks uses
>> \032\032([A-Za-z]:)([^:]+):([0-9]+):[0-9]+:[begmidl]+:(0x[0-9A-z]+)
> 
> Is that the only regex they use?  Because that doesn't look like it would match without the filename.  It also doesn't look like it would match MinGW gdb's output which is like:
> "  C:/tmp/mingwdbg/hello.c:22:496:beg:0x401322"
> 
> Note "beg" vs "begmidl".

I figured this one out :-)
I didn't notice the [] around "begmidl".

But I still don't see how it could match with your no-filename output. In fact it appears that it will only match with fully-qualified Windows filenames.  So there must be some other one they use at least to match

Ah yes... looks like they use this too:
  ([A-Za-z]*[:]*)([^:]+):([0-9]+):[0-9]+:[begmidl]+:(0x[0-9A-Fa-f]+)

That appears to be the main one actually.  The other one you gave is used for "disassembly-flavor or32", whatever that is.  --- oh, open risc 32.  Seems like it's a bug workaround.

--bb

ah, ic!
the missing filename isn't an output format issue. C::B requires the
full pathname, so i try to find it using the source search paths that
have been set with the "directory" command. if ddbg can't find the
absolute path, it doesn't output any filename - that's going to be fixed
in the next release.

hm, all these different GDB output formats are pretty annoying. any chance to make emacs work with GDB/MI (Machine Interface)?

Bill Baxter wrote:
> Here's some additional info I've found.
> 
> You probably already realized this, but this output
> "  C:/tmp/mingwdbg/hello.c:22:496:beg:0x401322"
> is also generated with the --fullname, which you're already supporting
> (actually you're generating --fullname output whether or not the flag is
> supplied :-P)
> 
> So I'm not sure why it doesn't already work.  The only difference I can
> see is that you omit the filename.
> "  :22:496:beg:0x401322"
> 
> and maybe emacs needs that filename there.
> 
> Can you try just adding the full filename to that output string?
> 
> That should enable emacs to at least display the current source line.
> 
> 
> Unfortunately I discovered there's another file called gdb-ui.el that implements most of the other nifty features of the gdb mode, like showing breakpoints etc.  It is triggered by finding "\n  prompt" in the output after "(gdb)" which is something --annotate prints.
> 
> The extended processing relies pretty heavily on the specific format of
> --annotate=3 output.
> Here's a url for gdb-ui.el for the record: http://tinyurl.com/25b6gw
> Specifically the thing to look for is the function
>   (defun gud-gdba-marker-filter ... )
> 
> 
> 
> --bb

Jascha Wetzel wrote:
> ah, ic!
> the missing filename isn't an output format issue. C::B requires the
> full pathname, so i try to find it using the source search paths that
> have been set with the "directory" command. if ddbg can't find the
> absolute path, it doesn't output any filename - that's going to be fixed
> in the next release.
> 
> hm, all these different GDB output formats are pretty annoying. any
> chance to make emacs work with GDB/MI (Machine Interface)?

From gdb-ui.el:

;; GDB developers plan to make the annotation interface obsolete.  A new
;; interface called GDB/MI (machine interface) has been designed to replace
;; it.  Some GDB/MI commands are used in this file through the CLI command
;; 'interpreter mi <mi-command>'.  A file called gdb-mi.el is included with
;; GDB (6.2 onwards) that uses GDB/MI as the primary interface to GDB. It is
;; still under development and is part of a process to migrate Emacs from
;; annotations to GDB/MI.

But my emacs (GNU Emacs 22.0.93.1) doesn't have such a thing, and MinGW's gdb (that I just downloaded) says it's version 5.2.1.

However, making it work sounds like it may be as easy as downloading the gdb-mi.el file and throwing it in one's site-lisp directory.
    http://tinyurl.com/yo2bq8
The comment in that file says it will work with emacs 22.x.

--bb

Bill Baxter wrote:
> Jascha Wetzel wrote:
>> ah, ic!
>> the missing filename isn't an output format issue. C::B requires the
>> full pathname, so i try to find it using the source search paths that
>> have been set with the "directory" command. if ddbg can't find the
>> absolute path, it doesn't output any filename - that's going to be fixed
>> in the next release.
>>
>> hm, all these different GDB output formats are pretty annoying. any
>> chance to make emacs work with GDB/MI (Machine Interface)?
> 
>  From gdb-ui.el:
> 
> ;; GDB developers plan to make the annotation interface obsolete.  A new
> ;; interface called GDB/MI (machine interface) has been designed to replace
> ;; it.  Some GDB/MI commands are used in this file through the CLI command
> ;; 'interpreter mi <mi-command>'.  A file called gdb-mi.el is included with
> ;; GDB (6.2 onwards) that uses GDB/MI as the primary interface to GDB. It is
> ;; still under development and is part of a process to migrate Emacs from
> ;; annotations to GDB/MI.
> 
> But my emacs (GNU Emacs 22.0.93.1) doesn't have such a thing, and MinGW's gdb (that I just downloaded) says it's version 5.2.1.
> 
> However, making it work sounds like it may be as easy as downloading the gdb-mi.el file and throwing it in one's site-lisp directory.
>     http://tinyurl.com/yo2bq8
> The comment in that file says it will work with emacs 22.x.
> 
> --bb


There is a gdb 6.x snapshot available for download on MinGW's site.
I tried that with the above gdb-mi.el.
It works, but not as well currently as --annotate=3 mode.
The indicators for breakpoints and current line don't show up for some reason, though I can't tell why.  It looks like it's supposed to work, judging from the comments in the code.

--bb

Bill Baxter wrote:
> But I still don't see how it could match with your no-filename output.

that no-filename output is a bug not related to the output (see other post)

> That appears to be the main one actually.  The other one you gave is used for "disassembly-flavor or32", whatever that is.  --- oh, open risc 32.  Seems like it's a bug workaround.

it's actually the same as the one in the line above that one, except for
requiring a drive-letter + colon and the "\032\032", which C::B needs in
any case (it checks that with a string.startswith before matching the
regex).
since the format i use is
"\032\032%s:%d:0:begmidl:0x%08x", file, line, address
those differences shouldn't be an issue. Note that i use that "begmidl"
just as a filler.

if it's just for these few changes - they will be in the next release. if i'll have to put a larger amount of work into the CLI issue, i'd really prefer implementing GDB/MI. besides the fact that something like GDB/MI is the most reasonable way to solve the problem, eclipse/cdt supports it as well.

Bill Baxter wrote:
> Bill Baxter wrote:
>> Jascha Wetzel wrote:
>>> ah, ic!
>>> the missing filename isn't an output format issue. C::B requires the
>>> full pathname, so i try to find it using the source search paths that
>>> have been set with the "directory" command. if ddbg can't find the
>>> absolute path, it doesn't output any filename - that's going to be fixed
>>> in the next release.
>>>
>>> hm, all these different GDB output formats are pretty annoying. any chance to make emacs work with GDB/MI (Machine Interface)?
>>
>>  From gdb-ui.el:
>>
>> ;; GDB developers plan to make the annotation interface obsolete.  A new
>> ;; interface called GDB/MI (machine interface) has been designed to
>> replace
>> ;; it.  Some GDB/MI commands are used in this file through the CLI
>> command
>> ;; 'interpreter mi <mi-command>'.  A file called gdb-mi.el is included
>> with
>> ;; GDB (6.2 onwards) that uses GDB/MI as the primary interface to GDB.
>> It is
>> ;; still under development and is part of a process to migrate Emacs from
>> ;; annotations to GDB/MI.
>>
>> But my emacs (GNU Emacs 22.0.93.1) doesn't have such a thing, and
>> MinGW's gdb (that I just downloaded) says it's version 5.2.1.
>>
>> However, making it work sounds like it may be as easy as downloading
>> the gdb-mi.el file and throwing it in one's site-lisp directory.
>>     http://tinyurl.com/yo2bq8
>> The comment in that file says it will work with emacs 22.x.
>>
>> --bb
> 
> 
> There is a gdb 6.x snapshot available for download on MinGW's site.
> I tried that with the above gdb-mi.el.
> It works, but not as well currently as --annotate=3 mode.
> The indicators for breakpoints and current line don't show up for some
> reason, though I can't tell why.  It looks like it's supposed to work,
> judging from the comments in the code.
> 
> --bb