On Sep 30, 2024, at 1:39 PM, Martin <li...@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 -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
