[Dwarf-discuss] Question on "pascal property"

[David Blaikie]

I'd be curious what compilers have been doing for Pascal for the last few
decades - not exactly a new problem? But, yeah, might've all been getting
by with extensions.

On Wed, May 1, 2024 at 2:47 PM Adrian Prantl via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20240501/028e8cf9/attachment-0001.htm>