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

[Martin]

Anyone care to comment on those ideas?

Are they worth to be made a feature request?
And if so, which of the proposed ideas should be made into a feature 
request?

On 11/09/2011 23:15, Martin wrote:
>
> Like it was done for properties that directly map to a field. The now 
> are somehow encoded, so the field is read.
> BTW anyone, why is that dwarf only => could stabs not just define 
> another entry under the property name?
>
>
> Even then it would be a long way, because it would only be in fpc 
> 2.6.2 (if merged) or 2.8.0; before a lazarus release would benefit.
> On the other hand it would anyway take time for lazarus to be adapted 
> to use the info. And currently the info would have to be readable 
> through gdb, something I hope to change in future.
>
> More than that, Lazarus is not the only way to use the info, people 
> use other IDEs or gdb directly => all that needs to be considered.
>
> Also there are (at least to me) 2 levels.
> 1) Make available the info that a property exists, even if no way 
> exists to access it. (via gdb)
> 2) access to the data, or information about hpw to access (pointer to 
> getter/setter functions) (via gdb)
>
> The first would simply mean that something in the "ptype" result of a 
> class indicates the presence of a property
>
> Of course, if the property already maps (aliases) the field (if 
> directly mapped to field) then it is impossible for ptype to return a 
> different result, than the type of the field.
>
> And returning the content of the field is essential, especially if 
> fields themself are structured types (classes).
>      FooObject.BarObjFieldProperty.BarValue
> only works with the current "alias" solution.
> While an IDE could transform the expression, if really that was 
> needed, a user using gdb directly would relay on this working (and for 
> an IDE it is much easier and leads to better performance, if that is 
> working)
>
> That already defies the idea of encoding properties as structure 
> (actually differnet properties = diff structures) with a field for 
> getter and setter.
> The structure could have been identified as property by a none pascal 
> name (like the $fp framepointer in nested functions)
>
> The structure approach would have been nice, as it would have provided 
> the info about the property in place of the real property name.
> - It would have been fine if  FooObject.BarObjFieldProperty  would 
> return and display the whole structure. An IDE can deal with it, and a 
> gdb user can still read it (assuming that the structure displays all 
> it's values, rather than just an address)
> - But it would break FooObject.BarObjFieldProperty.BarValue  . Unless 
> the "." after the property can be tought to be an operator that uses 
> the "read-value" field (if it is a field)
>   (and similar for arras with [])
>
> I am not sure if something like this can be done (and reliable with 
> current gdb versions)
>
> ---
> Another approach, by far not as nice:
>
> - Leave the getter as is / maybe add getters with function to declare 
> the property to be the same as the read function.
> - And add another field PropertyName$Set with the setter info
>
> Accessing a property in value evaluation would work as it does now.
> An IDE getting a "ptype" could detect the xxx$Set entries, match the 
> getters, and know what is a property => even have a way of modifying 
> them, if it can do code-execution for that purpose...
>
> Alternative xxx$Property with a record (or xxx$Set / xxx$get), to 
> provide info about properties; but leave the actual name mapped to the 
> field (were appropriate) so the expression evaluation would still work