[Dwarf-discuss] Extension for the new DW_TAG_property in DWARF-6

[Martin]

I found some cases that hadn't previously been considered.

1) Extending an inherited property
( **not** changing accessibility (public/private) / albeit that can 
happen at the same time)


program project1;
type
   TBase = class
     private    F1: integer;
     public     property v1: integer read F1;
   end;
   TFoo = class(TBase)
     protected FNew: integer;
     public    property v1 write FNew;
     // no type ": integer" => extend/modify inherited
  end;

var
   a: TFoo;
begin
   a := TFoo.Create;
   a.v1 := a.v1 + 1; // read (from TBase) and write
end.


With the current DW_TAG_property we might end up with
- TBase has DW_TAG_property  with only getter
- TFoo has DW_TAG_property with getter (repeated) and setter

But that means no distinction if the getter is newly defined or inherited.

Omitting the getter in TFoo would mean that we have a new property
   type TFoo = class(TBase) public property v1: integer ...
that no longer has a getter at all.

Repeating the getter with the same DW_TAG_property_forward as TBase 
would not allow to distinguish from that being a declared access to the 
same field.

Could we add that
   DW_TAG_property_getter (or setter/stored)
   without any children (including no DW_TAG_property_forward)
should mean to use the inherited getter?

Alternatively a DW_TAG_inheritance, but without DW_AT_TYPE, and instead 
a reference to the parent property could do.


2) properties accessing a value from an array

In the below example the value is an indexed member of an array.

program project1;{$Mode objfpc}
type
    T1 = array [3..5] of integer;
    T2 = array [1..8] of T1;
    R2 = record n: T2; end;

    TFoo = class
    private
      F1: T1;
      F2, F3: R2;
    public
      property Bar1: Integer read f1[4];
      // can be in a nested record
      property Bar2: Integer read F2.n[4][1];
      property Bar3: T1 read F2.n[4];
    end;


There is no DW_TAG_member or DW_TAG_variable for the single element of 
the array.
DW_AT_property_forward could only link to the array itself.
It would indicate that the value is from this array.

The optional DW_AT_location would be used to point to the structure 
(nested in TFoo).
- For "F1" there is no nested structure.
- For "F2.n" that is "F2", so it is known that "n" is not from "F3".

But there is no way at the moment to identify the entry inside the array.
It would additionally need the index (currently always a constant).

Also DW_AT_property_forward  pointing to the array means the type is not 
matching. The DW_AT_property_forward points to an array, but the 
property is of type integer. (albeit the type can be found by looking at 
the type of the array entries)


To solve that, I can think of various approaches.

A) Adding attributes to specify a (list of) index(es).
This would be the maximum verbose

B) repurpose DW_AT_location (omit DW_AT_property_forward_
- If (hopefully) the consumer does not need to know the address of the 
structure, then this could point to the final array element.
- OMIT DW_AT_property_forward
   If this points to the array, then (e.g. for Bar3) the consumer needs 
to compare the property and forward type, to detect they don't match.

C) Declare a dummy DW_TAG_Member inside the DW_TAG_property_getter
This is not a real field, but can be used to describe type and location.
This would allow to cover all kind of cases that may arise in future,
but it would obscure the relation ship to the real field holding the data.