Perhaps you could use an attribute with the full "path" as a string. I'm not sure it's high-value information, perhaps only useful for some sort of "info type" command that wants to describe the type.
On 10/12/24 16:59, Adrian Prantl via Dwarf-discuss wrote: > CAUTION! External Email. Do not click links or open attachments unless you > recognize the sender and are sure the content is safe. > If you think this is a phishing email, please report it by using the "Phish > Alert Report" button in Outlook. > > 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 -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
