Just a quick very general remark: For Objective-C, Clang (and presumably also GCC) are producing a couple of property-related attributes in the DW_AT_APPLE extension space
https://github.com/llvm/llvm-project/blob/505f6da1961ab55c601d7239648c53ce863b5d70/llvm/include/llvm/BinaryFormat/Dwarf.def#L630 maybe these are useful for you. I also wouldn't be opposed to standardizing a more generally useful mechanism for properties; we could potentially also find use for them in the Swift compiler. -- adrian > On May 1, 2024, at 4:24 AM, Martin via Dwarf-discuss > <dwarf-discuss@lists.dwarfstd.org> wrote: > > Hello, > > I am writing the below to see if any of this might be of interest to add new > tags/attributes to the Dwarf spec. > > If not, or for the parts for which it is a no, then I am happy to use vendor > extensions. > > > In Pascal there is a construct called property. > https://www.freepascal.org/docs-html/ref/refse27.html > > To the user (and to any code accessing it, it behaves like a variable in that > it can be read or assigned too. But it can not have its address taken. (The > last bit may be ignorable for the rest of this email) > > In the most basic form it provides a setter and getter, which can either be a > field or method. Setter and getter are always references to existing > fields/methods. > > In order to describe this to a debugger, I can see 2 features that could be > added to dwarf > > > 1) Probably a new DW_TAG_PROPERTY > > Albeit, it might be possible to sub-divide existing DW_TAG_Variable / > DW_TAG_Member into sub-sections, but I don't think that is advisable. > > The tag could then be sub-divided, as it needs the same info for different > accessors. DW_TAG_PROPERTY_xxxx where xxxx is > > - "reader" => description on how to get the value > - "setter" => description on how to write the value > - "default" => how to get the default value, if one exsits > - "stored" => information if this value should be serialized, if the object > is serialized (may depend on its vaule, can be a function) > - user..../other > > Alternatively to dividing it into accessor tags, there could be just > attributes for each method of access. Then however the below idea to allow > direct variable/member tags will not work. > > > The property would also be able to have attributes directly (not in sub > sections), like virtuality. > > And it could be without sub-sections, if it just changed virtuality. This is > common in Pascal, that a sub-class makes an inherited property more visible. > > > Maybe.... There would be the question, if existing variable/member could > benefit from any of that information. (I don't know a case were it would be > needed). If there was, then the variable/member would be encoded as it > currently is, but a DW_TAG_PROPERTY_WRITE[R] could be added, to override the > handling of how it is written. Just a thought. > > > 2) Forwarding to the existing member/method/function > > As indicated in Pascal the getter/setter are always a reference to an > existing field/getter. Though defaults/stored can be a constant too. > And to make it more flexible, it might be considered to allow embedding > DW_TAG_Variable / DW_TAG_Member directly? > > In Pascal the reference can be > - reference to a field or method > - references to a field or method in a different object (needs specification > of the target obj) > - reference to a function (not part of an object/structure) > > So the accessors could have a simple tag > > For forwarding the would need a new DW_AT_FORWARD or DW_AT_ALIAS (better > names may exist) attribute. > > References already exist. But they only reference the TAG describing the > value. They can't hold an object (e.g. for DW_OP_push_object_address). > > So there would also be the need for DW_AT_FORWARD_OBJECT. > > I don't know if there are cases where such an ref-with-object would be > interesting to existing encoding (such as when a ref is used to get the > bounds of an array) > > > > If the forwarder is to a function, then there is a need to know how to call > it. For a getter a function (or method, only taking the _this instance), the > "how to call" is implicit. > > For a setter, there needs to be an extra argument, to pass the value. This > could be implicit, if it is the only argument (other than maybe _this). > > > Pascal has properties, that can share a getter and share a setter. The > getter/setter then takes an index (of any type). > For this a description would be needed, how to call the function. > > DW_TAG_CALL_ARGUMENT_LIST with a list of DW_AT_CALL_ARGUMENT. (that could be > const, ref, expr), or Special values for _this and for "the value". > > -- > 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
