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

[Adrian Prantl]

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.

-- adrian