Hi,

examining the codeview symbols that DMD for windows generates, i've
found that it sets the symbol type of arrays to 0x23 which is UQUAD
(ulong in D). I can't find information on what the array's element type is.
Can it be determined from the CV data?
If not, shouldn't that be possible?
It would be kind of cumbersome to have to parse the source for that.

/jascha

Jascha Wetzel wrote:
> Hi,
> 
> examining the codeview symbols that DMD for windows generates, i've
> found that it sets the symbol type of arrays to 0x23 which is UQUAD
> (ulong in D). I can't find information on what the array's element type is.
> Can it be determined from the CV data?
> If not, shouldn't that be possible?
> It would be kind of cumbersome to have to parse the source for that.

I tried telling CV that arrays were really:

struct Array
{	size_t length;
	void *ptr;
}

but it would get hopelessly lost with functions that returned arrays.

How about using type mangling to add the complete array type to the
symbol name then? The mangled type could be separated from the actual
symbol name by an escape character invalid in D identifiers.
That wouldn't hurt non-D debuggers and would still enable D debuggers to
deal with arrays properly.

Walter Bright wrote:
> Jascha Wetzel wrote:
>> Hi,
>>
>> examining the codeview symbols that DMD for windows generates, i've
>> found that it sets the symbol type of arrays to 0x23 which is UQUAD
>> (ulong in D). I can't find information on what the array's element
>> type is.
>> Can it be determined from the CV data?
>> If not, shouldn't that be possible?
>> It would be kind of cumbersome to have to parse the source for that.
> 
> I tried telling CV that arrays were really:
> 
> struct Array
> {    size_t length;
>     void *ptr;
> }
> 
> but it would get hopelessly lost with functions that returned arrays.

thinking about it: why not simply mangle all data symbols just like function symbols?

Jascha Wetzel wrote:
> How about using type mangling to add the complete array type to the
> symbol name then? The mangled type could be separated from the actual
> symbol name by an escape character invalid in D identifiers.
> That wouldn't hurt non-D debuggers and would still enable D debuggers to
> deal with arrays properly.
> 
> Walter Bright wrote:
>> Jascha Wetzel wrote:
>>> Hi,
>>>
>>> examining the codeview symbols that DMD for windows generates, i've
>>> found that it sets the symbol type of arrays to 0x23 which is UQUAD
>>> (ulong in D). I can't find information on what the array's element
>>> type is.
>>> Can it be determined from the CV data?
>>> If not, shouldn't that be possible?
>>> It would be kind of cumbersome to have to parse the source for that.
>> I tried telling CV that arrays were really:
>>
>> struct Array
>> {    size_t length;
>>     void *ptr;
>> }
>>
>> but it would get hopelessly lost with functions that returned arrays.

Jascha Wetzel schrieb am 2007-01-17:
> thinking about it: why not simply mangle all data symbols just like function symbols?

Some "data symbols" never have a proper address apart from a register. "data symbols" in functions don't have a constant address (though they usually have a constant offset).

Thomas

Codeview doesn't support register symbols, afaik. Therefore local
symbols always have offsets into the stack frame. Debugging optimized
code is problematic either way...
To be precise, i should have written "stack data symbols". DMD mangles
types for global and local functions as well as global data, but doesn't
do so for local (stack-) data.

Thomas Kuehne wrote:
> Jascha Wetzel schrieb am 2007-01-17:
>> thinking about it: why not simply mangle all data symbols just like function symbols?
> 
> Some "data symbols" never have a proper address apart from a register. "data symbols" in functions don't have a constant address (though they usually have a constant offset).
> 
> Thomas
> 
> 

Jascha Wetzel wrote:
> Codeview doesn't support register symbols, afaik.

It does.

> Therefore local
> symbols always have offsets into the stack frame. Debugging optimized
> code is problematic either way...
> To be precise, i should have written "stack data symbols". DMD mangles
> types for global and local functions as well as global data, but doesn't
> do so for local (stack-) data.

The problem really is for function return types.

Walter Bright wrote:
> The problem really is for function return types.

Does that affect the naming of local symbols?
The CV types could be left the way they are and yet the complete array
type could be derived from the mangled name.
In fact, i'm manually emulating this ATM by using variable names with
mangled type information in my debuggee's source:

void debugeeFunc()
{
  // char[] test;
  char[] _D4testAa;
  // ...
}

the generated CV symbol looks like this:

S_BPREL32 UQUAD [ebp+FFFFFFF8] _D4testAa

It's fine to have it declared UQUAD, since with the mangled type info in the symbol name i can interpret the data at runtime properly.

Jascha Wetzel wrote:
> Walter Bright wrote:
>> The problem really is for function return types.
> 
> Does that affect the naming of local symbols?
> The CV types could be left the way they are and yet the complete array
> type could be derived from the mangled name.
> In fact, i'm manually emulating this ATM by using variable names with
> mangled type information in my debuggee's source:
> 
> void debugeeFunc()
> {
>   // char[] test;
>   char[] _D4testAa;
>   // ...
> }
> 
> the generated CV symbol looks like this:
> 
> S_BPREL32 UQUAD [ebp+FFFFFFF8] _D4testAa
> 
> It's fine to have it declared UQUAD, since with the mangled type info in
> the symbol name i can interpret the data at runtime properly.

That's possible. What debugger are you using?

Walter Bright wrote:
> That's possible. What debugger are you using?

I'm writing it ;)