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

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

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

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

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
      #### hello.d is actually ..\..\hello.d
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

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
>       #### hello.d is actually ..\..\hello.d
> 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