ddbg_gdb with emacs

Bill Baxter dnewsgroup at billbaxter.com
Mon Mar 5 17:14:59 PST 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
       #### 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


More information about the Digitalmars-d-debugger mailing list