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.

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.

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.

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?

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.

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

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.

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.

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.