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

lly, properties can be accessed like variables and data >> members, however,access is implemented by invoking user-defined or >> compiler-generated subprograms, allowing programmed constraints, including >> read-only and write-only semantics. >> >> Re 4: Good. I might have

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

examples and Chapter 7 changes, and a fix to accessibility. 2025-03-03: Discussed in meeting. Change "field" (Pascal term) to "data member" (DWARF term); add updates for App. A; update Table 7.32 for type signature computation. 2025-03-10: [Revised][diff4]. Removed Pascal-specific

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

Here is the latest revision: - Removed Pascal-specific wording from text in 5.19 (field -> data member) - added updates for Appendix A - updated Section 7.32 for type signature computation. -- adrian # Add support for "properties" ## Background Pascal has a property construct, that allows a "v

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

> On Feb 17, 2025, at 10:00 AM, Adrian Prantl wrote: > > 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 > perspe

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

* 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

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

I have note that I’m supposed to update the example in this proposal, but I neglected to write down what the expected change was. Does anyone remember what the problem in the current version was, and/or have any other feedback that I could incorporate? -- adrian > On Jan 3, 2025, at 11:18 PM,

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

Here is an updated version of the proposal, based on the discussion during the last meeting. Changes from the last revision: - fixed typo (DW_AT_location) - added table entries in chapter 7 - improved legibility of example -- adrian # Add support for "properties" ## Background Pascal has a pro

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

Please find attached a revised proposal based on feedback from this thread. -- adrian # Proposal to implement "properties" (based on Pascal) ## Background Pascal has a property construct, that allows a "variable like" identifier, which can either point to a field (member variable) or a getter/s

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

> On Oct 10, 2024, at 9:31 AM, Todd Allen via Dwarf-discuss > wrote: > > Adrian, > > This usage of DW_AT_specification seems very different from other uses > of DW_AT_specification, where it's indicating that the current DIE is a > completion of a forward declaration at the referenced DIE.

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

On Sep 30, 2024, at 1:39 PM, Martin wrote: > > 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.

Re: [Dwarf-discuss] Coroutines

CC'ing Felipe, who is currently reworking a lot of this code and is much deeper in the subject matter than me. -- adrian > On Oct 1, 2024, at 8:42 AM, Kyle Huey wrote: > > On Wed, Feb 28, 2024 at 10:02 AM Adrian Prantl wrote: >> LLDB implements this in a custom stepping

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

Hello Martin, sorry for the long delay for getting back to you. The DWARF committee was on hiatus over the summer but we're resuming regular meetings now and I would like to prepare this issue for discussion now. I have tried to remove everything from the proposal that could be considered an i

Re: [Dwarf-discuss] Question on Clang 18.1.8 and DW_IDX_parent

CC'ing Felipe Piovezan, who implement this feature, in case he wants to fill in more details. -- adrian > On Sep 3, 2024, at 10:06 AM, David Blaikie via Dwarf-discuss > wrote: > > Some context: > https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/44 >

Re: [Dwarf-discuss] Proposal: `DW_LNS_indirect_line`

> On Jul 8, 2024, at 2:18 PM, David Blaikie wrote: > > @Adrian Prantl <mailto:apra...@apple.com> and @Jonas Devlieghere > <mailto:jdevliegh...@apple.com> with the CAS DWARF stuff, how are you folks > separating line table fragments for functions? My understanding w

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

ault_value. > > At the moment Pascal only supports such redirects for "records" (i.e. > structures without reference, that are inlined into the parents memory). > For such structures the structure could be found from the memory location. > > But for a generic approach th

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

Hello Martin, Thanks for submitting your proposal! In order to prepare it for discussion I would suggest to first try pick a first choice for all the design options in the proposal and then once the direction is clear, distill the normative text changes that would need to be made in the DWARF s

Re: [Dwarf-discuss] Question on "pascal property"

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#

Re: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

s > wrote: > > On Wed, Apr 24, 2024 at 02:57:17PM -0700, Adrian Prantl wrote: >> >> >>> On Apr 24, 2024, at 2:49 PM, Jakub Jelinek wrote: >>> >>> On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss >>> wrote:

Re: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

> On Apr 24, 2024, at 2:49 PM, Jakub Jelinek wrote: > > On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss > wrote: >> # C standard release dates for DW_AT_language_version, clarify semantics >> >> ## Background >> >> The

Re: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

The back story here is that I am trying to implement the new language attributes in LLVM, which is why I'm finding all these bugs, omissions, and ambiguities: https://github.com/llvm/llvm-project/pull/89980 cheers, Adrian > On Apr 24, 2024, at 2:25 PM, Adrian Prantl via Dwarf

[Dwarf-discuss] Proposal: Add versioning scheme for Fortran

# Add versioning scheme for Fortran ## Background The list of languages at https://dwarfstd.org/languages-v6.html does not list a versioning scheme for Fortran, but we have DWARF 5 language constants for FORTRAN77 through Fortran08. ## Proposed Changes Augment the table of language encodings

[Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

# C standard release dates for DW_AT_language_version, clarify semantics ## Background The list of languages at https://dwarfstd.org/languages-v6.html does not list release dates for the ISO C standard. Producers need to know what version numbers they should produce though. I scanned the ISO we

Re: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

ed langiage is DW_LNAME_Hylo 0x0028. -- adrian > > Ron > > > On Tue, Apr 23, 2024 at 8:06 PM Adrian Prantl via Dwarf-discuss > mailto:dwarf-discuss@lists.dwarfstd.org>> > wrote: >> # Error: Duplicate DW_AT_LNAME 1d >> >> ## Overview >>

[Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d

# Error: Duplicate DW_AT_LNAME 1d ## Overview The list of DWARF Version 6 Language and Version Codes double-assigns the DW_AT_LNAME code 0x001d to "HIP" and "Assembly". ## Proposed Changes Reassign HIP to 0x0029. ## References https://dwarfstd.org/languages-v6.html -- Dwarf-discuss mailing

[Dwarf-discuss] Proposal: Define a language version scheme for Swift

# Swift Language version scheme ## Background The list of languages at https://dwarfstd.org/languages-v6.html does not list a version scheme for the Swift language. This proposal adds one. ## Overview The Swift programming language does not have a version scheme defined for DW_AT_language_ver

Re: [Dwarf-discuss] gfortran / gcc on Mac puts control characters in N_SO STABS

> On Mar 15, 2024, at 9:22 AM, John DelSignore via Dwarf-discuss > wrote: > > Thanks for looking at this. I sent a separate email with the object file > attached directly to you. > From my quick investigation the problem seems to be that gfortran uses a DW_FORM_string for the compile unit'

Re: [Dwarf-discuss] gfortran / gcc on Mac puts control characters in N_SO STABS

d_ports_lang_gcc13/gcc13/work/gcc-13.2.0/libgcc/ > - 00 SO emutls.c > - 01 SO > dc3-mac-tvt4 42 03/15 10:39 /tmp % > > Notice that the control characters in two "first" SO stabs. > > Do you agree this is a linker bug

Re: [Dwarf-discuss] gfortran / gcc on Mac puts control characters in N_SO STABS

The N_OSO stabs entries are indeed added by the linker (https://wiki.dwarfstd.org/Apple's_%22Lazy%22_DWARF_Scheme.md). Having done a quick scan through the linker sources I was not able to pinpoint the place where this path concatenation is happening. > FWIW, I have not seen a similar problem w

Re: [Dwarf-discuss] Coroutines

> On Feb 27, 2024, at 1:53 PM, Kyle Huey via Dwarf-discuss > wrote: > > Put another way (forgive my pseudo code), if you have > > function silly_print() { > delay = rand(); > // Point 1 > async_sleep(delay).await; > // Point 2 > printf("Hello" ); > } > > function do_stuff

Re: [Dwarf-discuss] Coroutines

> On Feb 27, 2024, at 10:32 AM, Kyle Huey wrote: > > On Wed, Feb 21, 2024 at 9:12 AM Adrian Prantl <mailto:apra...@apple.com>> wrote: >> Can you clarify what kind of information you are interested in? Are you >> talking about representing variables inside of

Re: [Dwarf-discuss] Coroutines

Can you clarify what kind of information you are interested in? Are you talking about representing variables inside of coroutines, function pointers to coroutines, linetables for coroutines, ...? LLDB's Swift plugin for example supports Swift async functions (which are effectively coroutines) b

Re: [Dwarf-discuss] Curiosity: Multiple Unwind Paths?

To my knowledge there is nothing in DWARF to capture this, but tools can use additional platform-specific information in addition to DWARF to provide a richer experience. For example, LLDB can display both the real call stack (from unwinding+DWARF) and the virtual call graph (by following corout

Re: [Dwarf-Discuss] lambda (& other anonymous type) identification/naming

> On Jan 23, 2022, at 2:53 PM, David Blaikie wrote: > > A rather common "quality of implementation" issue seems to be lambda naming. > > I came across this due to non-canonicalization of lambda names in template > parameters depending on how a source file is named in Clang, and GCC's seem >

Re: [Dwarf-Discuss] DW_AT values unknown to me.

Would you potentially be interested in contributing some of the missing vendor extensions to LLVM's DWARF parser (https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/BinaryFormat/Dwarf.def )?

Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?

> On Mar 19, 2020, at 5:49 PM, Michael Eager via Dwarf-Discuss > wrote: > > My reading of sections 2.5 & 2.6 is that you cannot have a DW_OP_piece in an > DWARF expression. > I wonder if this is an intentional part of the design because of ambiguity/correctness issues or is this just some

Re: [Dwarf-Discuss] variable locations - safe use as lvalues

> On Jan 20, 2020, at 2:20 PM, Frank Ch. Eigler via Dwarf-Discuss > wrote: > > Hi - > > I have a question about variable location lists, but not their > encoding, the use they are suitable for. The basic debugging scenario > is just reading variable values, for which this is fine, especiall

Re: [Dwarf-Discuss] dsymutil: "could not find referenced DIE" followed by a segmentation fault and other newbie questions

> On Dec 8, 2018, at 6:24 AM, Gil Moses via Dwarf-Discuss > wrote: > > Hi, > > Building with Xcode 7, once in a while I get the following warnings from the > dsymutil tool (a few dozens): > "could not find referenced DIE" > Followed be a segmentation fault. > > Adding the verbosity flag,

Re: [Dwarf-Discuss] multiple entry points for inlined subroutines?

I'm unfamiliar with the term "view number". Is that a GCC-specific extension? -- adrian > On Aug 11, 2017, at 6:25 AM, Alexandre Oliva wrote: > > I've been working on generating more precise entry points for inlined > subroutines in GCC. > > One of the goals of this was to provide the debug in

Re: [Dwarf-Discuss] New Dwarf tags

The LLVM source code has most tags annotated with the version number they were introduced in: https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/Dwarf.def -- adrian > On Jun 21, 2017,

Re: [Dwarf-Discuss] Semantics of DW_OP_(b)reg

> On Mar 20, 2017, at 9:59 AM, Jakub Jelinek wrote: > > On Mon, Mar 20, 2017 at 09:23:36AM -0700, Adrian Prantl wrote: >> >>> On Mar 17, 2017, at 2:49 PM, David Anderson wrote: >>> >>> On 03/17/2017 01:18 PM, Adrian Prantl wrote: >>>> Are

Re: [Dwarf-Discuss] Semantics of DW_OP_(b)reg

> On Mar 17, 2017, at 2:49 PM, David Anderson wrote: > > On 03/17/2017 01:18 PM, Adrian Prantl wrote: >> Are these two expressions equivalent? >> 1. DW_OP_breg1 0 DW_OP_breg2 0 DW_OP_plus DW_OP_stack_value >> 2. DW_OP_reg1DW_OP_reg2DW_OP_plus DW_OP_stack_valu

Re: [Dwarf-Discuss] Semantics of DW_OP_(b)reg

> On Mar 17, 2017, at 3:26 PM, David Anderson wrote: > > On 03/17/2017 02:54 PM, Adrian Prantl wrote: >> Would you say that the example in Appendix D, pg 291, line 23 >> DW_OP_entry_value 1 DW_OP_reg1 DW_OP_stack_value >> is incorrect, because DW_OP_ref is not al

Re: [Dwarf-Discuss] Semantics of DW_OP_(b)reg

> On Mar 17, 2017, at 2:49 PM, David Anderson wrote: > > On 03/17/2017 01:18 PM, Adrian Prantl wrote: >> Are these two expressions equivalent? >> 1. DW_OP_breg1 0 DW_OP_breg2 0 DW_OP_plus DW_OP_stack_value >> 2. DW_OP_reg1DW_OP_reg2DW_OP_plus DW_OP_stack_valu

[Dwarf-Discuss] Semantics of DW_OP_(b)reg

I have a couple of questions regarding the semantics of DW_OP_reg(x) and DW_OP_breg(x). LLVM's DWARF expression generator (which was written with DWARF 2 in mind) treats DW_OP_breg as synonymous with DW_OP_reg DW_OP_deref, but I get the impression that that may not be correct in DWARF 4+. Howeve

Re: [Dwarf-Discuss] DWARF piece questions

Here's my take on this. > On Dec 9, 2016, at 11:11 AM, Andreas Arnez wrote: > > Although I've already created public comments for (most of) this, > Michael Eager suggested that I post my questions regarding DWARF pieces > on this list (again). > > All of these questions are related to the defi

Re: [Dwarf-Discuss] Representing the location of smaller values in vector registers

> On Mar 9, 2016, at 8:36 AM, Michael Eager wrote: > > On 03/04/2016 01:12 PM, Adrian Prantl wrote: >> I have a best-practice kind of question: >> >> The x86_64 System V ABI passes floating point values in the xmm0, xmm1, ... >> 128-bit SSE vector register

Re: [Dwarf-Discuss] Representing the location of smaller values in vector registers

>> -Original Message- >> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On >> Behalf Of Adrian Prantl >> Sent: Friday, March 04, 2016 1:13 PM >> To: dwarf-discuss@lists.dwarfstd.org >> Subject: [Dwarf-Discuss] Representing the lo

[Dwarf-Discuss] Representing the location of smaller values in vector registers

I have a best-practice kind of question: The x86_64 System V ABI passes floating point values in the xmm0, xmm1, ... 128-bit SSE vector registers. I’m wondering what the correct DWARF v4 (lacking the DWARF 5 type conversions) expression for a 32-bit float in xmm0 is. Given the following program

[Dwarf-Discuss] Best practices for implementing new features?

There is currently a discussion on the clang mailing list regarding the DWARF representation for modules, and I was wondering what the recommended best practices for situations like this are. Clang supports Modules (http://clang.llvm.org/docs/Modules.html) for C, Objective-C, and C++, which are