Bug in ddbg: incorrect stack frame

[Ary Manzana]

Yes, sorry, I didn't install dmd correctly.

It's great that strings and arrays are printed this way now.

Jascha Wetzel escribió:
> yes, example:
> 
> import std.stdio;
> void foo() {
>     writefln("asdf");
> }
> void main(char[][] args) {
>     foo();
> }
> 
> 
> debugging it:
> 
> ->bp c:3
> Breakpoint set: chau.d:3 0x402013
> ->r
> ...
> Breakpoint 0 hit at chau.d:3 0x402013
>     writefln("asdf");
> ->us
> #0  chau.foo () at chau.d:3
> #1 0x00402038 in _Dmain (args = {
>   [0] = "C:\\Documents and Settings\\jascha\\My
> Documents\\working\\chau.exe"
> }) at chau.d:6
> #2 0x0040277c in _main () from dmain2
> #3 0x0040abed in _mainCRTStartup () from constart
> #4 0x7c816fd7 in ?? () from KERNEL32.dll
> 
> 
> Ary Manzana wrote:
>> Jascha Wetzel escribió:
>>> The stacktrace prints the function that contains the instruction pointer
>>> of each frame, not the function that allocated the frame.
>>> The code that corresponds to the line where the function is declared
>>> contains the enter opcode that allocates the stack frame for that
>>> function. That means that the frame does not exist until the next line.
>>> Therefore your proposed stacktrace isn't correct at that position.
>> Thanks for the clarification.
>>
>>> But I agree that the current version is misleading.
>>>
>>> Instead of
>>> <frame no.> <function containing IP> [at file:line | from module]
>>> it should be
>>> <frame no.> <function that created the frame> [at file:line | from
>>> module]
>>>
>>> In your example the ST would then be (note that line=3 in frame 0)
>>> #0 _Dmain (args = 0x0012ff4c00000001) at chau.d:3
>>> #1 0x004020b8 in _main () from dmain2
>>> #2 0x0040750d in _mainCRTStartup () from constart
>>> #3 0x7c816fd7 in ?? () from KERNEL32.dll
>>>
>>> i'll fix this in the next release.
>> Thanks!
>>
>>> BTW: did you use DMD 1.010 or older? he args parameter should be
>>> expanded correctly else...
>> What do you mean by expanded correctly? I just downloaded dmd 1.014 and
>> the args parameters is shown exactly the same. Should I see the args as
>> an array literal (args = ["arg1":"value1"], etc.) ?