digitalmars.D.debugger - ddbg_gdb with emacs
- Bill Baxter (80/80) Feb 27 2007 I was trying to see if maybe ddbg_gdb already worked with emacs and if
- Jascha Wetzel (11/115) Feb 27 2007 what do you mean by that "source" there?
- Bill Baxter (20/37) Feb 27 2007 Sorry that's what gdb outputs when you use "--annotate" instead of
- Bill Baxter (12/21) Feb 27 2007 I figured this one out :-)
- Jascha Wetzel (10/14) Feb 28 2007 it's actually the same as the one in the line above that one, except for
- Bill Baxter (22/22) Feb 27 2007 Here's some additional info I've found.
- Jascha Wetzel (9/42) Feb 27 2007 ah, ic!
- Bill Baxter (17/26) Feb 27 2007 From gdb-ui.el:
- Bill Baxter (8/39) Feb 27 2007 There is a gdb 6.x snapshot available for download on MinGW's site.
- Jascha Wetzel (6/51) Feb 28 2007 if it's just for these few changes - they will be in the next release.
- Bill Baxter (10/60) Feb 28 2007 If you fix the filename part of the --fullname status output string,
- Bill Baxter (15/20) Feb 28 2007 I just had a bit of exchange with the GDB folks and gdb-mi.el author on
- Jascha Wetzel (3/29) Mar 05 2007 does 0.0.4 work with emacs? i didn't check, just fixed the missing
- Bill Baxter (6/9) Mar 05 2007 It doesn't show line numbers still for some reason.
- Bill Baxter (40/52) Mar 05 2007 Figured it out. It works when exe and source are in the same directory.
- Jascha Wetzel (6/64) Mar 06 2007 oh, sure, for some reason i didn't get that the full pathname is the
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
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
Jascha Wetzel wrote:i'll have issue1 fixed in the next release. also "print" and "clear" will be added.Great!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:"ISSUE 2: [...] " source C:/tmp/mingwdbg/hello.c:22:"what do you mean by that "source" there?That's an emacs-regex thing. \( \) are group delimiters and ( ) are literal parentheses in emacs.(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.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
Bill Baxter wrote: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. --bbcodeblocks 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".
Feb 27 2007
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
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
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
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
Bill Baxter wrote:Jascha Wetzel wrote: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. --bbah, 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
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: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. --bbah, 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 28 2007
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). --bbBill Baxter wrote:Bill Baxter wrote:Jascha Wetzel wrote: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. --bbah, 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 28 2007
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
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
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
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
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