June 14, 2007
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.
June 14, 2007
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.
June 15, 2007
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.
June 15, 2007
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?
June 15, 2007
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.
June 15, 2007
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...
June 15, 2007
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.
June 15, 2007
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.
June 17, 2007
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.

Top | Discussion index | About this forum | D home