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

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

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