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
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
