• Jascha Wetzel (25/25) Feb 07 2007 Compiling http://ddbg.mainia.de/debuggee.d with dmd -g creates 2 type
• Walter Bright (3/31) Feb 07 2007 I can fix that too .
• Jascha Wetzel (4/11) Feb 07 2007 ok, great!

Jascha Wetzel <"[firstname]" mainia.de> writes:

Compiling http://ddbg.mainia.de/debuggee.d with dmd -g creates 2 type
strings for each class defined. One marked as a forward reference with
the name of the class and all other fields set to zero and one with all
fields filled out as expected and the name "<module_name>.<class_name>".
The symbols that are instances of the class point to the fwdref version.
This will only happen for classes defined in the module in which they
are used. Imported classes will only have the non-fwdref version with
full name.

My problem is, that i couldn't find out how to properly determine the
corresponding type string from a fwdref version (i.e. get from
<class_name> to <module_name>.<class_name>), since the module name isn't
declared in the debug info - it's used in mangled names, but not
associated with the (source) module it belongs to.

Am i missing something?

Another thing is that structs appear to never have fwdref versions of
their types like classes do. Instead, a struct always has a short name,
regardless of whether they are defined externally or in the same module.
This makes the names ambiguous if there are imported structs with
identical names as locally defined ones.
Since symbols will always point to the correct type string, this isn't
really a problem, it's just unexpectedly inconsistent with the way
classes are handled.

BTW - is there a reason why classes are declared as if they were
pointers to structs (leaf type 0x0005) instead of being pointers to
classes (leaf type 0x0004)?

Walter Bright <newshound digitalmars.com> writes:

Jascha Wetzel wrote:
 Compiling http://ddbg.mainia.de/debuggee.d with dmd -g creates 2 type
 strings for each class defined. One marked as a forward reference with
 the name of the class and all other fields set to zero and one with all
 fields filled out as expected and the name "<module_name>.<class_name>".
 The symbols that are instances of the class point to the fwdref version.
 This will only happen for classes defined in the module in which they
 are used. Imported classes will only have the non-fwdref version with
 full name.
 
 My problem is, that i couldn't find out how to properly determine the
 corresponding type string from a fwdref version (i.e. get from
 <class_name> to <module_name>.<class_name>), since the module name isn't
 declared in the debug info - it's used in mangled names, but not
 associated with the (source) module it belongs to.
 
 Am i missing something?
 
 Another thing is that structs appear to never have fwdref versions of
 their types like classes do. Instead, a struct always has a short name,
 regardless of whether they are defined externally or in the same module.
 This makes the names ambiguous if there are imported structs with
 identical names as locally defined ones.
 Since symbols will always point to the correct type string, this isn't
 really a problem, it's just unexpectedly inconsistent with the way
 classes are handled.

I think I can fix that.

 BTW - is there a reason why classes are declared as if they were
 pointers to structs (leaf type 0x0005) instead of being pointers to
 classes (leaf type 0x0004)?

I can fix that too <g>.

Jascha Wetzel <"[firstname]" mainia.de> writes:

ok, great!
with that and array types, we're just two steps away from complete
watches and value-expressions in DDBG :)

Walter Bright wrote:
 I think I can fix that.
 
 BTW - is there a reason why classes are declared as if they were
 pointers to structs (leaf type 0x0005) instead of being pointers to
 classes (leaf type 0x0004)?

 
 I can fix that too <g>.