January 17, 2007 Re: DMD's codeview types for arrays | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Jascha Wetzel | Jascha Wetzel wrote:
> Walter Bright wrote:
>> That's possible. What debugger are you using?
>
> I'm writing it ;)
Ahh, I see now.
| |||
Permalink
ReplyJanuary 21, 2007 Re: DMD's codeview types for arrays | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Walter Bright | Walter Bright wrote: > Jascha Wetzel wrote: >> Walter Bright wrote: >>> That's possible. What debugger are you using? >> >> I'm writing it ;) > > Ahh, I see now. I've put together an alpha version of my debugger, that uses mangled types, if available, in all symbol names to interpret the data at runtime: http://mainia.de/ddbg-0.1-alpha.zip Included is a test program that declares some of it's variables with mangled typenames, as i explained before. Some array expression evaluation already works if enough type information is available. Slicing only works for char arrays, yet. Here is an example debug session with the files from the above archive: C:>ddbg.exe debuggee.exe Process started ntdll.dll loaded KERNEL32.dll loaded USER32.dll loaded GDI32.dll loaded Unknown breakpoint hit at 0x7C901230 ->lsm src\debuggee.d ->bp deb:45 Breakpoint set: src\debuggee.d:45 0x40217c ->r IMM32.dll loaded ADVAPI32.dll loaded RPCRT4.dll loaded LPK.dll loaded USP10.dll loaded msvcrt.dll loaded Breakpoint 0 hit src\debuggee.d:45 0x40217c if ( _D4argsAAa.length > 1 ) ->ov src\debuggee.d:48 0x40219d writefln("No arguments today, boring..."); -> No arguments today, boring... src\debuggee.d:50 0x4021b6 uint[] _D4testGk = [0xdeadbeef, 0xbaadf00d, 0xf00baaa]; -> src\debuggee.d:51 0x4021db int index = 1; -> src\debuggee.d:52 0x4021e2 uint num_chars = printArgs(_D4argsAAa); ->in src\debuggee.d:24 0x402080 uint printArgs(char[][] _D4argsAAa) ->bp deb:38 Breakpoint set: src\debuggee.d:38 0x402157 ->r arg #0: C:\Documents and Settings\jascha\My Documents\working\ddbg\debuggee.exe Breakpoint 1 hit src\debuggee.d:38 0x402157 qwer q = new asdf; ->lsv Scope: uint debuggee.printArgs(char[][]) char[][] args [ebp+8] = ["C:\Documents and Settings\jascha\My Documents\working\ddbg\debuggee.exe"] uint numchars [ebp-72] = 0x0000004f char[] test [ebp-64] = "asdfqwer1234" float[] ztui [ebp-56] = [234.657806] void* _TMP1 [ebp-48] = 0x0012ff54 ulong _TMP2 [ebp-40] = 0x0012ff5400000001 int i [ebp-32] = 1 char[] a [ebp-24] = "C:\Documents and Settings\jascha\My Documents\working\ddbg\debuggee.exe" char[] numstr [ebp-16] = "0" [ebp-8] = Symbol q has unknown type (ddl says: [custom: 0x1003] q [bp-8]) ->= ztui[0] 234.657806 ->= args[0][0..12] "C:\Documents" ->da src\debuggee.d:38 qwer q = new asdf; 00402157: 6808414100 push dword 0x414108 0040215c: e8e3010000 call 0x402344 00402161: 8945f8 mov [ebp-0x8], eax src\debuggee.d:39 q.test2(); 00402164: 8b18 mov ebx, [eax] 00402166: ff5318 call dword near [ebx+0x18] src\debuggee.d:40 return numchars; 00402169: 8b45b8 mov eax, [ebp-0x48] 0040216c: 83c404 add esp, 0x4 src\debuggee.d:41 } 0040216f: 5f pop edi 00402170: 5e pop esi 00402171: 5b pop ebx 00402172: c9 leave 00402173: c20800 ret 0x8 ->q | |||
January 22, 2007 Re: DMD's codeview types for arrays | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Jascha Wetzel | Excellent! Keep up the good work!
So how far are you from having a fully usable debugger that works with plain, unmangled D source?
--bb
Jascha Wetzel wrote:
> Walter Bright wrote:
>> Jascha Wetzel wrote:
>>> Walter Bright wrote:
>>>> That's possible. What debugger are you using?
>>> I'm writing it ;)
>> Ahh, I see now.
>
> I've put together an alpha version of my debugger, that uses mangled
> types, if available, in all symbol names to interpret the data at runtime:
> http://mainia.de/ddbg-0.1-alpha.zip
>
> Included is a test program that declares some of it's variables with
> mangled typenames, as i explained before. Some array expression
> evaluation already works if enough type information is available.
> Slicing only works for char arrays, yet.
> Here is an example debug session with the files from the above archive:
>
> C:>ddbg.exe debuggee.exe
> Process started
> ntdll.dll loaded
> KERNEL32.dll loaded
> USER32.dll loaded
> GDI32.dll loaded
> Unknown breakpoint hit at 0x7C901230
> ->lsm
> src\debuggee.d
> ->bp deb:45
> Breakpoint set: src\debuggee.d:45 0x40217c
> ->r
> IMM32.dll loaded
> ADVAPI32.dll loaded
> RPCRT4.dll loaded
> LPK.dll loaded
> USP10.dll loaded
> msvcrt.dll loaded
> Breakpoint 0 hit src\debuggee.d:45 0x40217c
> if ( _D4argsAAa.length > 1 )
> ->ov
> src\debuggee.d:48 0x40219d
> writefln("No arguments today, boring...");
> ->
> No arguments today, boring...
> src\debuggee.d:50 0x4021b6
> uint[] _D4testGk = [0xdeadbeef, 0xbaadf00d, 0xf00baaa];
> ->
> src\debuggee.d:51 0x4021db
> int index = 1;
> ->
> src\debuggee.d:52 0x4021e2
> uint num_chars = printArgs(_D4argsAAa);
> ->in
> src\debuggee.d:24 0x402080
> uint printArgs(char[][] _D4argsAAa)
> ->bp deb:38
> Breakpoint set: src\debuggee.d:38 0x402157
> ->r
> arg #0: C:\Documents and Settings\jascha\My
> Documents\working\ddbg\debuggee.exe
> Breakpoint 1 hit src\debuggee.d:38 0x402157
> qwer q = new asdf;
> ->lsv
> Scope: uint debuggee.printArgs(char[][])
> char[][] args [ebp+8] = ["C:\Documents and Settings\jascha\My
> Documents\working\ddbg\debuggee.exe"]
> uint numchars [ebp-72] = 0x0000004f
> char[] test [ebp-64] = "asdfqwer1234"
> float[] ztui [ebp-56] = [234.657806]
> void* _TMP1 [ebp-48] = 0x0012ff54
> ulong _TMP2 [ebp-40] = 0x0012ff5400000001
> int i [ebp-32] = 1
> char[] a [ebp-24] = "C:\Documents and Settings\jascha\My
> Documents\working\ddbg\debuggee.exe"
> char[] numstr [ebp-16] = "0"
> [ebp-8] = Symbol q has unknown type (ddl says: [custom: 0x1003]
> q [bp-8])
> ->= ztui[0]
> 234.657806
> ->= args[0][0..12]
> "C:\Documents"
> ->da
> src\debuggee.d:38 qwer q = new asdf;
> 00402157: 6808414100 push dword 0x414108
> 0040215c: e8e3010000 call 0x402344
> 00402161: 8945f8 mov [ebp-0x8], eax
> src\debuggee.d:39 q.test2();
> 00402164: 8b18 mov ebx, [eax]
> 00402166: ff5318 call dword near [ebx+0x18]
> src\debuggee.d:40 return numchars;
> 00402169: 8b45b8 mov eax, [ebp-0x48]
> 0040216c: 83c404 add esp, 0x4
> src\debuggee.d:41 }
> 0040216f: 5f pop edi
> 00402170: 5e pop esi
> 00402171: 5b pop ebx
> 00402172: c9 leave
> 00402173: c20800 ret 0x8
> ->q
| |||
January 22, 2007 Re: DMD's codeview types for arrays | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | Bill Baxter wrote:
> Excellent! Keep up the good work!
> So how far are you from having a fully usable debugger that works with
> plain, unmangled D source?
thx!
that depends on what you think is usable ;)
you can use the alpha version with unmangled code, it will not
pretty-print arrays (shows them as ulong and you'll have to use memory
dumps to see the content), and thus array (debugger-)expressions can't
be evaluated either, but it should work otherwise.
besides stability, missing features are:
- CV custom types (i.e. struct/classes cannot be interpreted)
- debugging multiple threads isn't tested, could work though
- debugging child processes isn't tested and will probably not work
- attaching to running processes
- considering nested scopes (when unwinding the stack)
- more important stuff, that i don't think of right now
- conditional breakpoints
- module names for addresses outside the debug info
- lots of usability features (watchlists, etc.)
i'm also writing codeblocks integration, which isn't working quite
right, yet.
| |||
January 22, 2007 Re: DMD's codeview types for arrays | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Jascha Wetzel | Jascha Wetzel wrote:
> Walter Bright wrote:
>> Jascha Wetzel wrote:
>>> Walter Bright wrote:
>>>> That's possible. What debugger are you using?
>>> I'm writing it ;)
>> Ahh, I see now.
>
> I've put together an alpha version of my debugger, that uses mangled
> types, if available, in all symbol names to interpret the data at runtime:
> http://mainia.de/ddbg-0.1-alpha.zip
Can you please put together a web page for this? It's too important to be just a link to a zip file buried in a thread!
| |||
January 22, 2007 Re: DMD's codeview types for arrays | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote: > Can you please put together a web page for this? It's too important to be just a link to a zip file buried in a thread! done: http://ddbg.mainia.de/ shall i open a bugzilla issue for the type mangling of local symbols? | |||
January 23, 2007 Re: DMD's codeview types for arrays | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Jascha Wetzel | Jascha Wetzel wrote:
> Walter Bright wrote:
>> Can you please put together a web page for this? It's too important to
>> be just a link to a zip file buried in a thread!
>
> done: http://ddbg.mainia.de/
> shall i open a bugzilla issue for the type mangling of local symbols?
Sure, but I suggest a better way - add our own extension to CV data.
| |||
January 23, 2007 Re: DMD's codeview types for arrays | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote:
> Sure, but I suggest a better way - add our own extension to CV data.
ok, i can think of type leafs similar to this (notation according to CV
specs):
size content
2 LF_DYN_ARRAY (define as 0x0017)
2 @elemtype
and
2 LF_ASSOC_ARRAY (define as 0x0018)
2 @elemtype
2 @keytype
couldn't that also trigger the problem with functions returning such types?
| |||
January 23, 2007 Re: DMD's codeview types for arrays | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Jascha Wetzel | Jascha Wetzel wrote:
> Walter Bright wrote:
>> Sure, but I suggest a better way - add our own extension to CV data.
>
> ok, i can think of type leafs similar to this (notation according to CV
> specs):
> size content
> 2 LF_DYN_ARRAY (define as 0x0017)
> 2 @elemtype
>
> and
> 2 LF_ASSOC_ARRAY (define as 0x0018)
> 2 @elemtype
> 2 @keytype
>
> couldn't that also trigger the problem with functions returning such types?
No, because you can fix your debugger. What I'd do is the same thing I do with gdb, -g generates D debug info and needs a debugger aware of it, -gc generates C debug info for debuggers that aren't. In this case, the C debug info will not change.
| |||
January 24, 2007 Re: DMD's codeview types for arrays | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Walter Bright | Walter Bright wrote: > Jascha Wetzel wrote: >> Walter Bright wrote: >>> Sure, but I suggest a better way - add our own extension to CV data. >> >> ok, i can think of type leafs similar to this (notation according to CV >> specs): >> size content >> 2 LF_DYN_ARRAY (define as 0x0017) >> 2 @elemtype >> >> and >> 2 LF_ASSOC_ARRAY (define as 0x0018) >> 2 @elemtype >> 2 @keytype >> >> couldn't that also trigger the problem with functions returning such types? > > No, because you can fix your debugger. What I'd do is the same thing I do with gdb, -g generates D debug info and needs a debugger aware of it, Except that the stack backtrace is broken using -g (although it is possible to find _some_ linenumbers). Dropping -g works much better, although no line numbers are present. For reference, http://d.puremagic.com/issues/show_bug.cgi?id=136 -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi Dancing the Tango | |||
Copyright © 1999-2021 by the D Language Foundation