Ddbg 0.09 beta release

[dickl]

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.