www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Ddbg 0.09 beta release

reply Jascha Wetzel <firstname mainia.de> writes:
Ddbg is a Win32 D debugger

http://ddbg.mainia.de/releases.html

This release mainly improves on expressions and gives you access to all 
CPU/FPU/MMX/SSE registers.
See the documentation for details.
Jun 14 2007
next sibling parent reply dickl <dick221z yahoo.com> writes:
Jascha Wetzel wrote:

 Ddbg is a Win32 D debugger
 
 http://ddbg.mainia.de/releases.html
 
 This release mainly improves on expressions and gives you access to all 
 CPU/FPU/MMX/SSE registers.
 See the documentation for details.


The support for pointers and array are just what I need !!!!

There seems to be a problem with the integration in CodeBlocks though.
If I set a break point (anywhere) and start to debug, it never reaches 
the breakpoint. The debugger is started but appears to be hung. If I 
kill the debugger from CodeBlocks, the process isn't killed. I have use 
the task manager to kill it. Not sure where the problem lies as yet.

Running via the command line works fine.

I also noticed when using the command line , if I step 'in' on a 'new' 
statement, it goes to some totally unrelated line of code. All 
subsequent attempts at single stepping stay on the same line of code. If 
I use "ov" to get out,  then step with 'in' it steps into the 
constructor as it should.
Jun 14 2007
next sibling parent dickl <dick221z yahoo.com> writes:
dickl wrote:

 Jascha Wetzel wrote:

 Ddbg is a Win32 D debugger

 http://ddbg.mainia.de/releases.html

 This release mainly improves on expressions and gives you access to 
 all CPU/FPU/MMX/SSE registers.
 See the documentation for details.


 
 The support for pointers and array are just what I need !!!!
 
 There seems to be a problem with the integration in CodeBlocks though.
 If I set a break point (anywhere) and start to debug, it never reaches 
 the breakpoint. The debugger is started but appears to be hung. If I 
 kill the debugger from CodeBlocks, the process isn't killed. I have use 
 the task manager to kill it. Not sure where the problem lies as yet.
 
 Running via the command line works fine.
 
 I also noticed when using the command line , if I step 'in' on a 'new' 
 statement, it goes to some totally unrelated line of code. All 
 subsequent attempts at single stepping stay on the same line of code. If 
 I use "ov" to get out,  then step with 'in' it steps into the 
 constructor as it should.


The lockup problem with Codeblocks does not happen with ddbg 0.081.
Jun 14 2007
prev sibling parent reply Jascha Wetzel <firstname mainia.de> writes:
dickl wrote:

 There seems to be a problem with the integration in CodeBlocks though.


fixed in 0.09.1


 I also noticed when using the command line , if I step 'in' on a 'new' 
 statement, it goes to some totally unrelated line of code. All 
 subsequent attempts at single stepping stay on the same line of code. If 
 I use "ov" to get out,  then step with 'in' it steps into the 
 constructor as it should.


can you give me a test case for that?
Jun 14 2007
parent dickl <dick221z yahoo.com> writes:
Jascha Wetzel wrote:

 dickl wrote:

 There seems to be a problem with the integration in CodeBlocks though.


 
 fixed in 0.09.1
 

 I also noticed when using the command line , if I step 'in' on a 'new' 
 statement, it goes to some totally unrelated line of code. All 
 subsequent attempts at single stepping stay on the same line of code. 
 If I use "ov" to get out,  then step with 'in' it steps into the 
 constructor as it should.


 
 can you give me a test case for that?


Haven't been able to find a simple test case yet but have found this:

int result=1;

gc_init();			// initialize garbage collector
_minit();			// initialize module constructor table

The assembly list from ddbg looks like this:

 0x404032	// quantum.d:50    int result=1;
 0x404032	mov dword [ebp-0x54], 0x1
 0x404039	// quantum.d:52    gc_init();			// initialize garbage collector
 0x404039	call 0x440fd8	_gc_init audiosetup.d:116
 0x40403e	// quantum.d:53    _minit();			// initialize module constructor table
 0x40403e	call 0x441ea0	__minit audiosetup.d:116


Notice the source file for _gc_init & __minit are not correct, causing 
the debugger to show 116 of audiosetup.d while stepping into these function.


Now for 'new' statement, we get a similar thing

 0x40407b	// quantum.d:65		QuantumDlg dlg=new QuantumDlg();
 0x40407b	push dword 0x464cdc
 0x404080	call 0x4410cc	__d_newclass audiosetup.d:116
 0x404085	mov [ebp-0x24], eax
 0x404088	call 0x408154	quantumdlg.QuantumDlg._ctor quantumdlg.d:599


I've looked at the assembly listing from MSVC and the problem doesn't 
appear so it is a problem with ddbg.

Line 116 of audiosetup.d is the very last line in the file. audiosetup.d 
is the last file compiled/linked in.
Jun 17 2007
prev sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
Cool! Thanks!

It's nice that now everything is hidden in ..., so it's faster when 
integrating it into an IDE (more lazy).

I have a question: I tried inspecting an associative array.

char[][int] dictionary;
dictionary[1] = "one";
dictionary[2] = "one";

->= dictionary
{
   1 = ...,
   2 = ...
}
->= dictionary[1]
Invalid key type for associative array. Expected i found k

What does that mean?

Thanks,
Ary

Jascha Wetzel escribió:

 Ddbg is a Win32 D debugger
 
 http://ddbg.mainia.de/releases.html
 
 This release mainly improves on expressions and gives you access to all 
 CPU/FPU/MMX/SSE registers.
 See the documentation for details.
Jun 14 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
Ary Manzana wrote:

 I have a question: I tried inspecting an associative array.
 
 char[][int] dictionary;
 dictionary[1] = "one";
 dictionary[2] = "one";
 
 ->= dictionary
 {
   1 = ...,
   2 = ...
 }
 ->= dictionary[1]
 Invalid key type for associative array. Expected i found k
 
 What does that mean?


means you found a bug ;)
the types get output in mangled form (changed in 0.09.2). so the message 
says: i found a uint but needed an int.
integer constants are uints atm.
the bug you (implicitly) found is, that expressions may not be 
constants. that means neither "1" nor "cast(int)1" is a valid 
expression. therefore you couldn't fix this by writing 
"dictionary[cast(int)1]" - in 0.09.2 you can.
besides that, i will add implicit casts to handle this more smoothly, 
sometime...
Jun 15 2007
parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Jascha Wetzel wrote:

 Ary Manzana wrote:

 Invalid key type for associative array. Expected i found k

 What does that mean?


 
 means you found a bug ;)
 the types get output in mangled form (changed in 0.09.2). so the message
 says: i found a uint but needed an int.
 integer constants are uints atm.


Can't you mirror D in having integer constants be ints, with a 'u' or 'U' suffix
meaning unsigned (like 1u) and an 'L' suffix meaning long (like 1L, combine the
two to get the ulong 1UL)? Why deviate from the spec?

-- 
Remove ".doesnotlike.spam" from the mail address.
Jun 15 2007
parent Jascha Wetzel <firstname mainia.de> writes:
Deewiant wrote:

 Can't you mirror D in having integer constants be ints, with a 'u' or 'U'
suffix
 meaning unsigned (like 1u) and an 'L' suffix meaning long (like 1L, combine the
 two to get the ulong 1UL)? Why deviate from the spec?


constants just aren't really implemented, yet. what's there is basically 
a dummy (it's about 10 lines of code). i'll stick to the D specs in all 
aspects of expression syntax and semantics unless there's a really good 
reason not to.
Jun 15 2007