Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
June 14, 2007 Ddbg 0.09 beta release | ||||
---|---|---|---|---|
| ||||
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 Re: Ddbg 0.09 beta release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jascha Wetzel | 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 Re: Ddbg 0.09 beta release | ||||
---|---|---|---|---|
| ||||
Posted in reply to dickl | 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 Re: Ddbg 0.09 beta release | ||||
---|---|---|---|---|
| ||||
Posted in reply to dickl | 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 Re: Ddbg 0.09 beta release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jascha Wetzel | 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 Re: Ddbg 0.09 beta release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Manzana | 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 Re: Ddbg 0.09 beta release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jascha Wetzel | 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 Re: Ddbg 0.09 beta release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Deewiant | 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 Re: Ddbg 0.09 beta release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jascha Wetzel | 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. |
Copyright © 1999-2021 by the D Language Foundation