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