Playing devil's advocate here: Can you mix these two types of properties? That is, something like the following (please excuse any wrong syntax):
type TMyRecord = record a,b: integer; end; TMyClass = class function GetProp: TMyRecord; procedure SetProp(AVal: TMyRecord); property MyProp: TMyRecord read GetProp write SetProp; property MyPropA: integer read MyProp.a; end; That is, a read of TMyClass's MyPropA would call TMyClass.GetProp and then return only its member a? On 10/13/24 04:15, Martin via Dwarf-discuss wrote: > > On 13/10/2024 00:59, Adrian Prantl via Dwarf-discuss wrote: >> 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. >> > 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. > -- > Dwarf-discuss mailing list > Dwarf-discuss@lists.dwarfstd.org -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
