Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

[Jonas Maebe]

On 12 Sep 2011, at 20:20, Martin wrote:

> On 12/09/2011 19:14, Martin wrote:
>> Currently properties that map to a field are already present in dwarf (again why not in stabs?).

Because Stabs is legacy and I don't want to spend time on it.

>> Could not properties mapping to a function be implemented the same way => normal functions are already listed in "ptype" so
>>  public
>>  property Counter: Integer read GetCounter
>> could appear the same as the function "GetCounter" ?
>> 
>> In that case at least the list of available symbols is complete. The only thing that then would need codetools involved was to check if the name is a property and not a function/field.

That may be possible, yes.

> Maybe they can even in both cases (field or function) be encoded as "internal pointer" (the same that is used vor "var param" or objects, if I underatnad them correctly?
> 
> They do auto deref if used , but in ptype some gdb show them , so they can be detected (and where gdb does not show them special, they will be detectable if debug info is read by the IDE, bypassing gdb (planned for future))

I don't understand this idea. A var parameter is in fact a pointer at the machine code level. A field or method used to implement a property isn't in any way different from other fields or methods. You probably also should not rely on var-parameters being shown as pointer types in gdb, since that's most likely a gdb implementation detail.

> Adding declared-in-unit info: not sure if it will help much. afaik codetools has no problem finding that.

It cannot know from which unit the type comes. It's even not necessarily a type that is visible in the current unit.


Jonas