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

[Martin]

On 12/09/2011 19:31, Jonas Maebe wrote:
> On 12 Sep 2011, at 20:20, Martin wrote:
>
>>> 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.

That would be good... :)

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

You are right that wasn't thought through. They can't be, there is no 
pointer-value....

I was looking if there is by any chance any kind of small flag that 
could be embedded. yet would not chnage the behaviour for gdb.
Double nice if it can be displayed via gdb, but even if not, then in 
future the IDE could read it.

I have not much knowledge of dwarf yet, so all my ideas are more or less 
random attempt...

what is DW_AT_sibling used for?
could a property be a sibling of the field?

from dwarf 3 specs:
> In cases where a producer of debugging information feels that it will 
> be important for consumers of that information to quickly scan chains 
> of sibling entries, while ignoring the children of individual 
> siblings, that producer may attach a DW_AT_sibling attribute to any 
> debugging information entry. The value of this attribute is a 
> reference to the sibling entry of the entry to which the attribute is 
> attached

Sounds like it is just like a "hint" that any compiler 
(debug-info-producer) can add as it wants?



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

That depends:

if we speak of the declared type => then it should be visible?
if we speak of the actual instance type => then true.

We are not talking about virtual methods. (though we might get there, if 
we have to resolve a function)

We are speaking about properties. IIRC, if a property gets re-declared 
in child classes, then resolution is by declared type?


---
I am sure there is a lot more that could be added. I saw thereeven is a 
field for "with" blocks.

And there will be a need for variables from parents in case of nested 
procedures

procedure Outer;
var i: integer;
   procedure Middle;
      procedure Inner;
      begin
         writeln(i); // from outer
      end;
   var i: integer;  // middle // not in scope for inner
   begin end;
begin end;

Currently we just search parent frames => but that means to get the "i" 
from middle.