Discussion:
Can't get ddbg to work in Code::Blocks
Patrick Byrne
2007-03-30 12:14:11 UTC
Permalink
[ re-posted from digitalmars.D newsgroup ]

I have Code::Blocks installed (looks ace)
Selected (default) compiler is 'Digital Mars D compiler'
- compiler settings has 'add symbolic debug info [-g]' checked
- linker settings has, under 'Other linker options', '-g'
- Tool chain executables
- debugger is ddbg_gdb.exe (and I copied ddbg.exe to
c:\dmd\bin\ddbg_gdb.exe)
'debugger initialization commands' is blank


When I try to step in to my 'hello world' program I get:
Building to ensure sources are up-to-date
Build succeeded
Selecting target: Debug
Adding source dir: c:\d\dmd\bin
Adding source dir: c:\d\hworld\
Adding source dir: c:\d\hworld\
Adding file: bin\Debug\hworld.exe
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Program exited
Debugger finished with status 0
<<<<<<<<<<<<

...the program runs fine on the command line.

Any ideas, please?

-P
Jascha Wetzel
2007-03-30 13:03:05 UTC
Permalink
please post ddbg's output as described here:

(re-post from d.D)

check settings > compiler and debugger > debugger settings > display
debugger's log
you'll have a message tab "Debugger (debug)" which displays almost all
of the communication between codeblocks and ddbg.
ddbg will probably give a more verbose error message that you'll find there.
alternatively you can also try debugging your program on the command
line to find the problem.
Post by Patrick Byrne
[ re-posted from digitalmars.D newsgroup ]
I have Code::Blocks installed (looks ace)
Selected (default) compiler is 'Digital Mars D compiler'
- compiler settings has 'add symbolic debug info [-g]' checked
- linker settings has, under 'Other linker options', '-g'
- Tool chain executables
- debugger is ddbg_gdb.exe (and I copied ddbg.exe to
c:\dmd\bin\ddbg_gdb.exe)
'debugger initialization commands' is blank
Building to ensure sources are up-to-date
Build succeeded
Selecting target: Debug
Adding source dir: c:\d\dmd\bin
Adding source dir: c:\d\hworld\
Adding source dir: c:\d\hworld\
Adding file: bin\Debug\hworld.exe
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Program exited
Debugger finished with status 0
<<<<<<<<<<<<
...the program runs fine on the command line.
Any ideas, please?
-P
Patrick Byrne
2007-03-30 13:22:15 UTC
Permalink
Post by Jascha Wetzel
(re-post from d.D)
check settings > compiler and debugger > debugger settings > display
debugger's log
you'll have a message tab "Debugger (debug)" which displays almost all
of the communication between codeblocks and ddbg.
ddbg will probably give a more verbose error message that you'll find there.
alternatively you can also try debugging your program on the command
line to find the problem.
Sorry, I already did that. Output is the same:
Building to ensure sources are up-to-date
Build succeeded
Selecting target: Debug
Adding source dir: c:\d\dmd\bin
Adding source dir: c:\d\hworld\
Adding source dir: c:\d\hworld\
Adding file: bin\Debug\hworld.exe
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Program exited
Debugger finished with status 0
<<<<<<<<<<<<

Guess I will try command-line debugging. :-(
Jascha Wetzel
2007-03-30 13:28:47 UTC
Permalink
this is not the ddbg output.
note that there are two tabs, one called "Debugger" and one called
"Debugger (debug)". the former holds short infos from CB that are
independent of the debugger, the latter is the tab that holds the ddbg
output and what codeblocks sends to ddbg as input.

don't worry - if you're trying command-line debugging, you just do that
to fix this problem and get back to CB after that ;)
Post by Patrick Byrne
Post by Jascha Wetzel
(re-post from d.D)
check settings > compiler and debugger > debugger settings > display
debugger's log
you'll have a message tab "Debugger (debug)" which displays almost all
of the communication between codeblocks and ddbg.
ddbg will probably give a more verbose error message that you'll find there.
alternatively you can also try debugging your program on the command
line to find the problem.
Building to ensure sources are up-to-date
Build succeeded
Selecting target: Debug
Adding source dir: c:\d\dmd\bin
Adding source dir: c:\d\hworld\
Adding source dir: c:\d\hworld\
Adding file: bin\Debug\hworld.exe
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Program exited
Debugger finished with status 0
<<<<<<<<<<<<
Guess I will try command-line debugging. :-(
Patrick Byrne
2007-03-30 13:45:38 UTC
Permalink
Post by Jascha Wetzel
this is not the ddbg output.
note that there are two tabs, one called "Debugger" and one called
"Debugger (debug)". the former holds short infos from CB that are
independent of the debugger, the latter is the tab that holds the ddbg
output and what codeblocks sends to ddbg as input.
I see no 'Debugger (debug)' tab. I presume you mean the 'Code::Blocks
Debug' tab, which has lots of stuff on it.

All that the debugger adds (after pressing 'Step-in') is:
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 1, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
Post by Jascha Wetzel
don't worry - if you're trying command-line debugging, you just do that
to fix this problem and get back to CB after that ;)
Well, this is my attempt at debugging so far:

C:\d\hworld>\dmd\bin\ddbg_gdb.exe bin\Debug\hworld.exe
Ddbg v0.0.5.3 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/

(gdb) break main
Breakpoint 0 at 0x00000000
(gdb) run
Error: couldn't write breakpoint opcode at :0
(gdb) n
Warning: Unknown command 'n' ignored!
(gdb) next
ERROR: Couldn't read from process' memory for disassembly: Only part of
a ReadProcessMemory or WriteProcessMemory request was completed.

....I haven't used gdb before, but all does not seem to be well!

<* * *>

If I just start and run I get:

C:\d\hworld>\dmd\bin\ddbg_gdb.exe bin\Debug\hworld.exe
Ddbg v0.0.5.3 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/

(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
Program exited
(gdb)

....which flashes up a DOS box, presumably with the 'hello world'
output, though it doesn't wait for a key press as it should. If I run
the program from Code::Blocks (without trying to step) it works ok:

hello world
args.length = 1
args[0] = 'c:\d\hworld\bin\Debug\hworld.exe'

Process returned 0 (0x0) execution time : 0.015 s
Press any key to continue.


....most odd!


-P
Jascha Wetzel
2007-03-30 13:54:32 UTC
Permalink
did you check "settings > compiler and debugger > debugger settings >
display debugger's log"?
this enables the "Debugger (debug)" tab.
Post by Patrick Byrne
(gdb) break main
Breakpoint 0 at 0x00000000
break only accepts file:line locations, yet.
try somehting like "break main.d:1".

also you will have to "run" the process before using "next" (i will fix
that).
check out http://ddbg.mainia.de/doc.html for an example debug session
with the Ddbg syntax. i'd recommend using Ddbg syntax on the command
line, since Ddbg's GDB mode isn't as verbose.
Post by Patrick Byrne
Post by Jascha Wetzel
this is not the ddbg output.
note that there are two tabs, one called "Debugger" and one called
"Debugger (debug)". the former holds short infos from CB that are
independent of the debugger, the latter is the tab that holds the ddbg
output and what codeblocks sends to ddbg as input.
I see no 'Debugger (debug)' tab. I presume you mean the 'Code::Blocks
Debug' tab, which has lots of stuff on it.
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 1, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
[14:38:28.951]: Scanned 0 files for #includes, cache used 0, cache updated 0
Post by Jascha Wetzel
don't worry - if you're trying command-line debugging, you just do that
to fix this problem and get back to CB after that ;)
C:\d\hworld>\dmd\bin\ddbg_gdb.exe bin\Debug\hworld.exe
Ddbg v0.0.5.3 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/
(gdb) break main
Breakpoint 0 at 0x00000000
(gdb) run
Error: couldn't write breakpoint opcode at :0
(gdb) n
Warning: Unknown command 'n' ignored!
(gdb) next
ERROR: Couldn't read from process' memory for disassembly: Only part of
a ReadProcessMemory or WriteProcessMemory request was completed.
....I haven't used gdb before, but all does not seem to be well!
<* * *>
C:\d\hworld>\dmd\bin\ddbg_gdb.exe bin\Debug\hworld.exe
Ddbg v0.0.5.3 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/
(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
Program exited
(gdb)
....which flashes up a DOS box, presumably with the 'hello world'
output, though it doesn't wait for a key press as it should. If I run
hello world
args.length = 1
args[0] = 'c:\d\hworld\bin\Debug\hworld.exe'
Process returned 0 (0x0) execution time : 0.015 s
Press any key to continue.
....most odd!
-P
Patrick Byrne
2007-03-30 14:06:34 UTC
Permalink
Post by Jascha Wetzel
did you check "settings > compiler and debugger > debugger settings >
display debugger's log"?
this enables the "Debugger (debug)" tab.
I did, I did!

Perhaps this is broken in the latest CB build (downloaded today).
Post by Jascha Wetzel
Post by Patrick Byrne
(gdb) break main
Breakpoint 0 at 0x00000000
break only accepts file:line locations, yet.
try somehting like "break main.d:1".
Ok, working now, ta:

C:\d\hworld>\dmd\bin\ddbg_gdb.exe bin\Debug\hworld.exe
Ddbg v0.0.5.3 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/

(gdb) break hello.d:1
Breakpoint 0 at 0x00402010
(gdb) run
..
msvcrt.dll loaded
??hello.d:3:0:begmidl:0x00402010
(gdb) next
??hello.d:5:0:begmidl:0x00402014...
Post by Jascha Wetzel
also you will have to "run" the process before using "next" (i will fix
that).
great!
Post by Jascha Wetzel
check out http://ddbg.mainia.de/doc.html for an example debug session
with the Ddbg syntax. i'd recommend using Ddbg syntax on the command
line, since Ddbg's GDB mode isn't as verbose.
....but Code::Blocks will need to work with the gdb syntax, I presume?

-P
Jascha Wetzel
2007-03-30 14:13:37 UTC
Permalink
Post by Patrick Byrne
C:\d\hworld>\dmd\bin\ddbg_gdb.exe bin\Debug\hworld.exe
Ddbg v0.0.5.3 alpha - D Debugger
Copyright (c) 2007 Jascha Wetzel
http://ddbg.mainia.de/
(gdb) break hello.d:1
Breakpoint 0 at 0x00402010
(gdb) run
..
msvcrt.dll loaded
??hello.d:3:0:begmidl:0x00402010
(gdb) next
??hello.d:5:0:begmidl:0x00402014...
this looks like stepping works. now you just need to check what the
output looks like in CB and compare.
Post by Patrick Byrne
....but Code::Blocks will need to work with the gdb syntax, I presume?
yep. the difference is only syntax and detail of the output. therefore i
recommend the Ddbg syntax when troubleshooting the debugger on the
command line.
Patrick Byrne
2007-03-30 14:15:48 UTC
Permalink
Jascha Wetzel wrote:

I have have found the 'Debugger (debug)' tab. It was just off-screen
<shame>.
Post by Jascha Wetzel
also you will have to "run" the process before using "next"
Ok. That is what I was not doing. I have been accustomed for a while to
start debugging in visual Studio with 'step-in'. Sorry.

It seems to be working just fine now. Thanks.

-P

Frits van Bommel
2007-03-30 13:56:30 UTC
Permalink
Post by Patrick Byrne
Post by Jascha Wetzel
this is not the ddbg output.
note that there are two tabs, one called "Debugger" and one called
"Debugger (debug)". the former holds short infos from CB that are
independent of the debugger, the latter is the tab that holds the ddbg
output and what codeblocks sends to ddbg as input.
I see no 'Debugger (debug)' tab. I presume you mean the 'Code::Blocks
Debug' tab, which has lots of stuff on it.
There should also be a "Debugger (debug)" tab after you turn the
mentioned option on.
In some screen resolutions not all tabs may fit on the screen though. In
that case, you should use the two small triangles to the right of the
tabs to scroll them.

[snip]
Post by Patrick Byrne
....which flashes up a DOS box, presumably with the 'hello world'
output, though it doesn't wait for a key press as it should.
Are you sure it should wait? Code::Blocks by default runs console apps
through a wrapper that asks for a key press, but since you're running
the program without it that won't happen unless the program explicitly
asks for one itself.
Patrick Byrne
2007-03-30 14:08:13 UTC
Permalink
Post by Frits van Bommel
There should also be a "Debugger (debug)" tab after you turn the
mentioned option on.
In some screen resolutions not all tabs may fit on the screen though. In
that case, you should use the two small triangles to the right of the
tabs to scroll them.
got it now. It was off screen. Sorry - I am unfamiliar with this style
of gui furniture. ;-)
Post by Frits van Bommel
[snip]
Post by Patrick Byrne
....which flashes up a DOS box, presumably with the 'hello world'
output, though it doesn't wait for a key press as it should.
Are you sure it should wait? Code::Blocks by default runs console apps
through a wrapper that asks for a key press, but since you're running
the program without it that won't happen unless the program explicitly
asks for one itself.
Ok thanks.

-P
Loading...