[Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties)

[Martin]

On 13/10/2024 00:59, Adrian Prantl via Dwarf-discuss wrote:
> On Sep 30, 2024, at 1:39 PM, Martin <lists@mfriebe.de> wrote:
>>
>> On 30/09/2024 19:30, Adrian Prantl wrote:
>>> PS: One thing I left out is DW_AT_Property_Object. It wasn't clear to me why this wouldn't always be the address of the parent object of the DW_TAG_property.
>>
>> There is a construct where a property can point to an embedded structure.
>>
>> type
>> TMyRecord = record
>>    a,b: integer;
>> end;
>>
>> TMyClass = class
>>    FPadding: word;
>>    FData: TMyRecord;
>>    FOther: TMyRecord; // Can't use the type to search for FData
>>    property ValA: integer read FData.a;
>> end;
>>
>> In that case DW_AT_Property_Forward  points to the member "a" in "TMyRecord". This would be a DW_TAG_Member, which would have a DW_AT_data_member_location relative to the structure FData address. However there is no address where MyRecord is stored.
> 
> Interesting example! In this case a DW_TAG_property_getter needs to point to the member "a" of the field FData specifically, so it can't be a reference to the DW_TAG_member "a" in TMyRecord. I can't think of a good way of preserving the access path of the field here. We could allow a DW_AT_location + DW_AT_type to allow a consumer to derive the value, but not the access path. In the general case (think something like "read FBinaryTree.left.left.right.data") we lack the expressivity to preserve which sub-field in the data structure, since DWARF does not encode expressions, only types.
> 
> I think it would be reasonable to allow the common case of referring to a top-level field via a DW_TAG_member ref, and having an arbitrary DWARF expression in a DW_AT_location to recover the location in all other cases.
> 
Well, I don't think we need the "access path", as in full access path. 
As you pointed out "a" could be in a nested record of TMyRecord, but I 
can't think of any case where that access path would matter.

If we add DW_AT_Location:
- keep the normal fields in the property, including the refernce to "a"
- add DW_AT_Location to overwrite the DW_AT_data_member_location
then, yes we have all the info we need.

There is a choice to make that DW_AT_Location point directly to the data 
of the field. Or to the location of the directly enclosing object.

My original idea was to describe the location of "FData" with a location 
expression, and then the debugger still adds the 
DW_AT_data_member_location to that.

Currently directly specifying the location of the "pointed to field" is 
the simplest way.

And currently, in Pascal, the above only works for fields in a record. 
So the address of the record containing the field should never be 
needed. But if that ever is extended (or if any other language allows) 
to use a getter method from such an object, then the object address 
would be needed for the "this" parameter.
So maybe it is saver to use the DW_AT_Location to specify the address of 
that containing object?

In either case, the nested object can be different for getter/setter. So 
that additional address must given per getter/setter.