[Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties)

[Martin]

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.



The proposed text IMHO covers my ideas. I made a few comments below.



> ## Proposed Changes
> 
> ### Table 2.1
> add `DW_TAG_property`.
> 
> ### 5.7.6 add the following normative text
> 
> #### `DW_TAG_property`
> 
> Non-normative: Many object-oriented languages like Pascal and Objective-C have properties, which are member functions that syntactically behave like data members of an object. Pascal can also have global properties.
> 
> A property is represented by a debugging information entry with the
> tag `DW_TAG_property`. At property entry has a `DW_AT_name` string
> attribute whose value is the property name. A property entry has a
> `DW_AT_type` attribute to denote the type of that property.

Technically the DW_AT_type can be optional, at least for Pascal. It will 
always be the same as the type of the getter and setter.
I don't know if that is true for all other languages.


> 
> A property may have `DW_AT_Accessibility`, `DW_AT_external`, `DW_AT_virtuality`, `DW_AT_start_scope`, `DW_AT_decl_column`, `DW_AT_decl_file` and `DW_AT_decl_line` attributes with the respective semantics described for these attributes for `DW_TAG_member` (see chaper 5.7.6).
> 
> A property may have one or several of `DW_TAG_property_getter`, `DW_TAG_property_setter`, or `DW_TAG_property_stored` children to represent the getter and setter (member) functions, or the Pascal-style `stored` accessor for this property. Each of these tags have a `DW_AT_specification` attribute to point to a (member) function declaration. > They may also have `DW_TAG_formal_parameter` children that can have 
`DW_AT_default_value` attributes to declare additional default arguments 
for when these functions are used as property accessors.

Maybe clarify how they are mapped? They could have the same name as in 
the function?
Or are the mapped by position? (empty ones for params without default)?

I see from the example that it is by position. ok.
If there are no further defaults after a parameter, do the remaining 
empty DW_TAG_formal_parameter have to be given, or can they be omitted?


> Some languages can automatically derive accessors for properties from a field in the object. In such cases the `DW_AT_specification` attribute of the accessor entry may point to the `DW_TAG_member` entry of the field that holds the properties underlying storage.



> 
> To change the accessibility of a property in an inherited class, a `DW_TAG_property` can be specified with just a name and accessibility.
> For example if in a subclass property a becomes private it is sufficient to add the following to the subclass entry:
> ```
>     DW_TAG_property
>       DW_AT_name            "a"
>       DW_AT_accessibility   DW_ACCESS_private
> ```
> 

Oxygene has different visibility for read/write access
https://docs.elementscompiler.com/Oxygene/Members/Properties/#visibility

Maybe allow DW_AT_accessibility in the getter/setter tags too.



> 
> ### D Examples
> 
> Add
> 
> #### Properties
> 
> The properties in the Pascal object in this example is represented by the following DWARF.
> ```
> TClass = class
>       FField: integer;
>       function GetProp: integer;
>       procedure SetProp(AVal: Integer);
>       property MyProp: integer read GetProp write SetProp;
>       property MyOtherProp: integer read FField;
>       function GetFoo(x: word; AIndex: Integer): char;
>       property Foo[x: word]: char index 1 read GetFoo;
> end;
> 
> ```
...
>    DW_TAG_property
>      DW_AT_name "Foo"
> 
>      DW_TAG_property_getter
>        DW_AT_specification <ref to GetFoo>
>         DW_TAG_formal_parameter  ; _this (no default specified, details inherited from GetFoo
>         DW_TAG_formal_parameter
>             DW_AT_default_value <DW_OP_lit 1> ; property index
>         DW_TAG_formal_parameter  ; x (no default specified)
> ```
> 

The DW_TAG_formal_parameter for "x" and "index" appear to be swapped in 
order?