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
