Hi everyone,

Here is the latest update to the property proposal based on the feedback I’ve 
received so far.

Martin, can you check that everything in here makes sense from a Pascal 
perspective?

Changes include:
- moved to a new Section 5.19 since properties can be global
- added example for the “stored” keyword
- fixed the accessibility override mechanism to use 
DW_TAG_accessibility_declaration

-- adrian

o DWARF Committee Meeting (2025-02-03)

## Attendees

* Todd Allen
* Pedro Alves
* David Anderson
* David Blaikie
* Ron Brender
* Andrew Cagney
* Cary Coutant
* John DelSignore
* Jonas Devlieghere
* Jini Susan George
* Tommy Hoffner
* Jakub Jelinek
* Simon Marchi
* Markus T Metzger
* Jeremy Morse
* Adrian Prantl
* Hafiz Abid Qadeer
* Paul Robinson
* Tom Russell
* Fāng-ruì Sòng
* Caroline Tice
* Tony Tye
* Keith Walker
* Brock Wyma
* Jian Xu
* Zoran Zaric

## Agenda

* Upcoming meeting schedule:
    * February 17: No meeting (Presidents Day in US)
    * March 3: Meeting
    * March 17: Meeting (time changes to 9:00 PDT/1600 UTC)
* Review action items (below).
* Proposal discussion (below).

## Issues Awaiting Revision

* 221105.1 Add a mechanism for specifying subprogram return value locations (Andrew C.)
* 230109.1 Values for optimized out arguments (Jakub J.)
* 230120.2 Clarifications for Location Descriptions (Tony T.)
* 230120.3 Extend Memory Location Descriptions (Tony T.)
* 230524.1 Location Descriptions on the DWARF Stack (Tony T./Cary C.)
* 230529.2 Outlined Subroutines (Jakub J.)
* 230530.1 Data Sharing Attribute (Jakub J.)
* 231110.3 DWARF Extension Registry (Mark W.)

## Incomplete Issues

* 161109.1 Fortran deferred length (Jakub J.)
* 161109.2 DW_OP_call* alternative (Jakub J.)
* 210219.2 Tuple and struct types for Rust (Fāng-ruì S.)
* 220513.1 Java bytecode index (Jini G.)

## Action Items

* (Andrew C.) Add examples to 221105.1 Add a mechanism for specifying subprogram return value locations.
* (Mark W.) Revise 231110.3 DWARF Extension Registry: wording changes from Dec. 9 meeting, integrate new paragraphs into existing ones in 1.3.
* (David A.) Revise 240618.1 DW_AT_rnglists_base in Table F.1 and 240618.2 DW_AT_rnglists_base missing. Clarify where DW_AT_rnglists_base can be used and add .debug_ranges.dwo to Appendix F. (DONE: 240618.1 has been withdrawn, 240618.2 revised)
* (Jakub J.) Revise 230529.2 Outlined Subroutines. Use new attribute instead of DW_AT_abstract_origin, resolve what DIE the attribute should reference.
* (Jakub J.): Revise 230109.1 Values for optimized out arguments. Needs clarification re: matching of parameters, use of formal parameter type.
* (Jakub J.): Revise 230530.1 Data Sharing Attribute.
* (David B.) Check with originator about withdrawing 230206.1 Add DW_AT_imported_declaration entries to name index.
* (Cary C./David B.) Draft proposal re LTO issues.

## Issue Discussion

### 240507.1 Add support for “properties” (Adrian P.)

* Generalized the original wording to make it useful for languages other than Pascal (Obj-C, Swift).
* Updated examples to cover private members.
* Avoid describing language semantics.
* Given that properties can be global, 5.7.x. . Still a class declaration .

**Action Item**:

* Revise example to include stored property in the example.
* Figure out in which section this should go.
* Check with originator that the proposed solution works for them.

### 240618.2 DW_AT_rnglists_base missing (David A.)

* `DW_AT_rnglists_base` only belong in skeletons and non-split debug info.
* Producers started generating it in places we didn't intend it to be.
* Only point is to give you the location in the original executable. If you don't need relocation, you don't need base.
* Should we legitimize this? Consensus is **no** based on the original intent.

**Continue the discussion over email**.

### 250118.1 DW_AT_discr_value improvement (TBD)

* Chased back to DWARF 2, where it was added.
* Should say what it contains and let the table tell you.
    * Is table 7.5 normative? Yes.
* Consensus that we don't want to restrict it to LEB128.

**Accepted**: proposal (a) (remove the sentence)

### 250122.1 DW_AT_object_pointer: clarify wording around implicit versus explicit object parameters (Adrian P.)

* Have wording in the spec that for a member function, there is a self or this pointer. These tag formal parameters always have a `DW_AT_artificial`.
* Examples of languages where it's not implicit: C++23, Python.
* Nit: attributes are present, not "true".
* Consensus to remove the sentence and keep the non-normative text describing `DW_AT_artificial`.

**Accepted**
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Reply via email to