[Dwarf-discuss] Question on "pascal property"

Adrian Prantl aprantl@apple.com
Wed May 1 21:46:43 GMT 2024


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20240501/b2bbd39c/attachment.htm>


More information about the Dwarf-discuss mailing list