Hi!

When setting a breakpoint at the start of a function (where the name of the function is) the stack frame listing (us) is incorrect: it dosen't include the before-last stack frame.

Example file 1 (chau.d):

----------------------------------------------------
module chau;

void foo() {            // Line 3
	bar();
}

void main(char[][] args) {
	foo();          // Line 8
}
----------------------------------------------------

####################################################
C:\d\proj>ddbg chau
Ddbg 0.08 beta - D Debugger
Copyright (c) 2007 Jascha Wetzel
see http://ddbg.mainia.de/doc.html for documentation

Loading symbols from chau
->bp chau:3
Breakpoint set: chau.d:3 0x402010
->r
ntdll.dll loaded
KERNEL32.dll loaded
USER32.dll loaded
GDI32.dll loaded
Breakpoint 0 hit at chau.d:3 0x402010
void foo() {
->us
#0  chau.foo () at chau.d:3
#1 0x004020b8 in _main () from dmain2
#2 0x0040750d in _mainCRTStartup () from constart
#3 0x7c816fd7 in ?? () from KERNEL32.dll
####################################################

Should be:
#0  chau.foo () at chau.d:3
#1 0x0040202c in _Dmain (args = 0x0012ff4c00000001) at chau.d:8
#2 0x004020b8 in _main () from dmain2
#3 0x0040750d in _mainCRTStartup () from constart
#4 0x7c816fd7 in ?? () from KERNEL32.dll


Example file 2:

----------------------------------------------------
module chau;

void bar() {             // Line 3
}

void foo() {
	bar();           // Line 7
}

void main(char[][] args) {
	foo();           // Line 11
}
----------------------------------------------------

####################################################
C:\d\proj>ddbg chau
Ddbg 0.08 beta - D Debugger
Copyright (c) 2007 Jascha Wetzel
see http://ddbg.mainia.de/doc.html for documentation

Loading symbols from chau
->bp hola:3
Soure file "hola" not found
->bp chau:3
Breakpoint set: chau.d:3 0x402010
->r
ntdll.dll loaded
KERNEL32.dll loaded
USER32.dll loaded
GDI32.dll loaded
Breakpoint 0 hit at chau.d:3 0x402010
void bar() {
->us
#0  chau.bar () at chau.d:3
#1 0x0040202c in _Dmain (args = 0x0012ff4c00000001) at chau.d:11
#2 0x004020c4 in _main () from dmain2
#3 0x0040750d in _mainCRTStartup () from constart
#4 0x7c816fd7 in ?? () from KERNEL32.dll
####################################################

Should be:
#0  chau.bar () at chau.d:3
#1 0x0040202c in char.foo () at chau.d:7
#2 0x0040202c in _Dmain (args = 0x0012ff4c00000001) at chau.d:11
#3 0x004020c4 in _main () from dmain2
#4 0x0040750d in _mainCRTStartup () from constart
#5 0x7c816fd7 in ?? () from KERNEL32.dll

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

BTW: did you use DMD 1.010 or older? he args parameter should be expanded correctly else...

Ary Manzana wrote:
> Hi!
> 
> When setting a breakpoint at the start of a function (where the name of
> the function is) the stack frame listing (us) is incorrect: it dosen't
> include the before-last stack frame.
> 
> Example file 1 (chau.d):
> 
> ----------------------------------------------------
> module chau;
> 
> void foo() {            // Line 3
>     bar();
> }
> 
> void main(char[][] args) {
>     foo();          // Line 8
> }
> ----------------------------------------------------
> 
> ####################################################
> C:\d\proj>ddbg chau
> Ddbg 0.08 beta - D Debugger
> Copyright (c) 2007 Jascha Wetzel
> see http://ddbg.mainia.de/doc.html for documentation
> 
> Loading symbols from chau
> ->bp chau:3
> Breakpoint set: chau.d:3 0x402010
> ->r
> ntdll.dll loaded
> KERNEL32.dll loaded
> USER32.dll loaded
> GDI32.dll loaded
> Breakpoint 0 hit at chau.d:3 0x402010
> void foo() {
> ->us
> #0  chau.foo () at chau.d:3
> #1 0x004020b8 in _main () from dmain2
> #2 0x0040750d in _mainCRTStartup () from constart
> #3 0x7c816fd7 in ?? () from KERNEL32.dll
> ####################################################
> 
> Should be:
> #0  chau.foo () at chau.d:3
> #1 0x0040202c in _Dmain (args = 0x0012ff4c00000001) at chau.d:8
> #2 0x004020b8 in _main () from dmain2
> #3 0x0040750d in _mainCRTStartup () from constart
> #4 0x7c816fd7 in ?? () from KERNEL32.dll
> 
> 
> Example file 2:
> 
> ----------------------------------------------------
> module chau;
> 
> void bar() {             // Line 3
> }
> 
> void foo() {
>     bar();           // Line 7
> }
> 
> void main(char[][] args) {
>     foo();           // Line 11
> }
> ----------------------------------------------------
> 
> ####################################################
> C:\d\proj>ddbg chau
> Ddbg 0.08 beta - D Debugger
> Copyright (c) 2007 Jascha Wetzel
> see http://ddbg.mainia.de/doc.html for documentation
> 
> Loading symbols from chau
> ->bp hola:3
> Soure file "hola" not found
> ->bp chau:3
> Breakpoint set: chau.d:3 0x402010
> ->r
> ntdll.dll loaded
> KERNEL32.dll loaded
> USER32.dll loaded
> GDI32.dll loaded
> Breakpoint 0 hit at chau.d:3 0x402010
> void bar() {
> ->us
> #0  chau.bar () at chau.d:3
> #1 0x0040202c in _Dmain (args = 0x0012ff4c00000001) at chau.d:11
> #2 0x004020c4 in _main () from dmain2
> #3 0x0040750d in _mainCRTStartup () from constart
> #4 0x7c816fd7 in ?? () from KERNEL32.dll
> ####################################################
> 
> Should be:
> #0  chau.bar () at chau.d:3
> #1 0x0040202c in char.foo () at chau.d:7
> #2 0x0040202c in _Dmain (args = 0x0012ff4c00000001) at chau.d:11
> #3 0x004020c4 in _main () from dmain2
> #4 0x0040750d in _mainCRTStartup () from constart
> #5 0x7c816fd7 in ?? () from KERNEL32.dll

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

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

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

Yea that is awesome :).

Ary Manzana wrote:
> 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.) ?