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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
