↑ ↓ ← → Ary Manzana <ary esperanto.org.ar>
writes:
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 <"[firstname]" mainia.de>
writes:
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
↑ ↓ ← → Ary Manzana <ary esperanto.org.ar>
writes:
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.) ?
↑ ↓ ← → Jascha Wetzel <"[firstname]" mainia.de>
writes:
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.) ?
↑ ↓ ← → Ary Manzana <ary esperanto.org.ar>
writes:
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.
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...
the args parameters is shown exactly the same. Should I see the args as
an array literal (args = ["arg1":"value1"], etc.) ?
↑ ↓ ← → Charlie <charlie.fats gmail.com>
writes:
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.
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...
the args parameters is shown exactly the same. Should I see the args as
an array literal (args = ["arg1":"value1"], etc.) ?