[fpc-pascal] properties // Re: fpDebug function-call proof-of-concept

[Martin Frb]

On 07/07/2020 15:04, Joost van der Sluis wrote:
>
> Op 07-07-2020 om 12:41 schreef Christo Crause via fpc-pascal:
>>
>> Great news! I guess this is a step towards evaluating object 
>> properties via get methods?
>
> That is the final goal, yes.

For this, we will need to start looking at improving the DWARF info.
And most probably adding some vendor specific info.

Afaik, even Dwarf 5 does not supply those

We should probably start a wiki on this....

1) Encoding a property. This could be done by:
- Currently properties already point to the Field.
   That could in future be: point to either the field or the getter. => 
Thus any debugger could read the info.
   The type of the property might point to a function declaration (for 
other debuggers)

- Adding a DW_AT_fpc_type_property attribute to the type, so FpDebug 
knows it is a property
   This would be added to DW_Tag_Member  Or for global properties to 
DW_Tag_Variable.
   => FpDebug would (in case of a function) show the property as the 
result type of the function.    (that does not apply for function refs)

- Adding a sub tag    DW_TAG_fpc_setter
   This contains the description of the setter/or the field
   It could be left empty, if the outer TAG describes a field, and the 
setter is direct field access.

The absence of the DW_TAG_fpc_setter would mean a read-only property
Alternatively the outer tag can have DW_AT_fpc_type_property_readable 
DW_AT_fpc_type_property_writeable


2) Extra info for managed data (ansistring, dyn array, smart pointer)
Managed data needs to be marked with DW_AT_fpc_managed
Also maybe DW_AT_fpc_managed_copy_on_write
- This would also make ansistrings distinguishable from 
pchar/array-of-char. Though for that ansistring could also have 
DW_AT_fpc_longstring.

There would also need to be info on
- initial default value: nil
- incref / decref
- alloc mem, for initializing/changing with a value that the user 
specified in the debugger
   Foo('abc') needs to create a string 'abc'.
   Modifying the value of an existing string, also needs this.

3) calling convention?
Not sure what information already exists.


----------------
Outside the scope of function calling:

- the dwarf info for nested procedures, and the outer variables that 
they can access, could be improved.
Currently there is some scope info lacking.

- Each unit should have a list of other units, in correct search order.
So global symbols can be found according to pascal scope.

- file of text /file of record
I still haven't figured out what the dwar specs try to archive with 
their definition.
It defines a type, but there is no data to be viewed.
Some users have pointed to what "stabs" did => exposing the internal 
filehandle, so one can see if the file is open. Not exactly "correct" 
but more useful than what dwarf offers.
I have no idea/preference what should happen on this. Just throwing it in.