www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - ddbg_gdb with emacs

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 27 2007
next sibling parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
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
Feb 27 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 27 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 27 2007
parent Jascha Wetzel <"[firstname]" mainia.de> writes:
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.
Feb 28 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 27 2007
parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
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
Feb 27 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 27 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 27 2007
parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
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
Feb 28 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Jascha Wetzel wrote:

 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.


If you fix the filename part of the --fullname status output string, 
that should at least make emacs able to track the current line for now, 
which is better than nothing.

Sinking a bunch of time into emulating --annotate output is probably a 
bad idea though, since emacs, the gdb team, and the rest of the world 
are moving away from it.

I don't know why M-x gdbmi wasn't working for me (with the real gdb 6.2) 
but I suspect that'll get fixed eventually).

--bb


 
 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
Feb 28 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jascha Wetzel wrote:

 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.


I just had a bit of exchange with the GDB folks and gdb-mi.el author on 
the gdb mailing list.  Apparently gdb-mi.el is still under development 
and needs work.  And it also needs the latest bleeding edge gdb.  Well, 
version 6.6 anyway, which is newer than you can get from MinGW or Cygwin.

So I wasn't able to get the MI mode working in emacs.  But in theory it 
should work if you emulate what gdb 6.6 spits out.  And if not, then in 
theory it should work /eventually/ as more bugs are worked out of the 
emacs mode.

Unfortunately, since I haven't been able to confirm that gdb-mi mode 
works in emacs, that means I can't be a very useful tester of ddbg when 
it comes to emacs and gdb-MI emulation.  I can tell you if it works -- 
but if it doesn't work then it's just as likely to be a problem with the 
gdb-mi code as with your emulation.

--bb
Feb 28 2007
parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
does 0.0.4 work with emacs? i didn't check, just fixed the missing
filename issue and added "print".

Bill Baxter wrote:

 Jascha Wetzel wrote:

 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.


 
 I just had a bit of exchange with the GDB folks and gdb-mi.el author on
 the gdb mailing list.  Apparently gdb-mi.el is still under development
 and needs work.  And it also needs the latest bleeding edge gdb.  Well,
 version 6.6 anyway, which is newer than you can get from MinGW or Cygwin.
 
 So I wasn't able to get the MI mode working in emacs.  But in theory it
 should work if you emulate what gdb 6.6 spits out.  And if not, then in
 theory it should work /eventually/ as more bugs are worked out of the
 emacs mode.
 
 Unfortunately, since I haven't been able to confirm that gdb-mi mode
 works in emacs, that means I can't be a very useful tester of ddbg when
 it comes to emacs and gdb-MI emulation.  I can tell you if it works --
 but if it doesn't work then it's just as likely to be a problem with the
 gdb-mi code as with your emulation.
 
 --bb
Mar 05 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jascha Wetzel wrote:

 does 0.0.4 work with emacs? i didn't check, just fixed the missing
 filename issue and added "print".
 


It doesn't show line numbers still for some reason.
I'll try to figure out why, but may be a while.

But at least it is easier to run without having to type the full path to 
the exe now.  :-)

--bb
Mar 05 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Figured it out.  It works when exe and source are in the same directory.
But if the source actually lives _up_ the file system hierarchy from the 
current directory then ddbg_gdb will omit the full path to the source 
file for some reason.

F:\test\cbtestproj\bin\Debug>ddbg_gdb.exe -nx --fullname -args \
    cbtestproj.exe
Ddbg v0.0.4.1 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/
(gdb) break hello.d:18

Breakpoint 0 at 0x00402017
(gdb) run
ntdll.dll  loaded
KERNEL32.dll  loaded
USER32.dll  loaded
GDI32.dll  loaded
IMM32.dll  loaded
ADVAPI32.dll  loaded
RPCRT4.dll  loaded
LPK.dll  loaded
USP10.dll  loaded
msvcrt.dll  loaded
GoogleDesktopNetwork3.DLL  loaded
WS2_32.dll  loaded
WS2HELP.dll  loaded
→→hello.d:18:0:begmidl:0x00402017
(gdb) q


The directory structure above comes from CodeBlocks.  Emacs gdb mode 
seems to try to be 'helpful' by always changing the current directory to 
that of the .exe.  So I was actually telling it to do
   ddbg_gdb.exe -nx --fullname -args bin\Debug\cbtestproj.exe
from the source directory, but it cd's down to the exe directory 
automatically anyway.  It seems like util.getFullPath is maybe not doing 
it's thing properly?

Another tiny thing -- in Emacs it's apparent that the dll names are 
getting suffixed with a null character.  I see in coff.d you explicitly 
add the null to the coff image's m_name.  That seems to be the culprit.

--bb

Bill Baxter wrote:

 Jascha Wetzel wrote:

 does 0.0.4 work with emacs? i didn't check, just fixed the missing
 filename issue and added "print".


 
 It doesn't show line numbers still for some reason.
 I'll try to figure out why, but may be a while.
 
 But at least it is easier to run without having to type the full path to 
 the exe now.  :-)
 
 --bb
Mar 05 2007
parent Jascha Wetzel <"[firstname]" mainia.de> writes:
oh, sure, for some reason i didn't get that the full pathname is the
problem. ddbg will output the full pathname whenever it can find the
file from it's source search paths, which always include the current
directory.
i'll add the proper --fullname behaviour in the next release.

Bill Baxter wrote:

 Figured it out.  It works when exe and source are in the same directory.
 But if the source actually lives _up_ the file system hierarchy from the
 current directory then ddbg_gdb will omit the full path to the source
 file for some reason.
 
 F:\test\cbtestproj\bin\Debug>ddbg_gdb.exe -nx --fullname -args \
    cbtestproj.exe
 Ddbg v0.0.4.1 alpha - D Debugger
 Copyright (c) 2007 Jascha Wetzel
 http://ddbg.mainia.de/
 (gdb) break hello.d:18

 Breakpoint 0 at 0x00402017
 (gdb) run
 ntdll.dll  loaded
 KERNEL32.dll  loaded
 USER32.dll  loaded
 GDI32.dll  loaded
 IMM32.dll  loaded
 ADVAPI32.dll  loaded
 RPCRT4.dll  loaded
 LPK.dll  loaded
 USP10.dll  loaded
 msvcrt.dll  loaded
 GoogleDesktopNetwork3.DLL  loaded
 WS2_32.dll  loaded
 WS2HELP.dll  loaded
 →→hello.d:18:0:begmidl:0x00402017
 (gdb) q
 
 
 The directory structure above comes from CodeBlocks.  Emacs gdb mode
 seems to try to be 'helpful' by always changing the current directory to
 that of the .exe.  So I was actually telling it to do
   ddbg_gdb.exe -nx --fullname -args bin\Debug\cbtestproj.exe
 from the source directory, but it cd's down to the exe directory
 automatically anyway.  It seems like util.getFullPath is maybe not doing
 it's thing properly?
 
 Another tiny thing -- in Emacs it's apparent that the dll names are
 getting suffixed with a null character.  I see in coff.d you explicitly
 add the null to the coff image's m_name.  That seems to be the culprit.
 
 --bb
 
 Bill Baxter wrote:

 Jascha Wetzel wrote:

 does 0.0.4 work with emacs? i didn't check, just fixed the missing
 filename issue and added "print".


 It doesn't show line numbers still for some reason.
 I'll try to figure out why, but may be a while.

 But at least it is easier to run without having to type the full path
 to the exe now.  :-)

 --bb
Mar 06 2007