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

s.dwarfstd.org>> wrote: >>>> >>>> Thanks, Adrian and Ron. I went ahead and applied the grammatical changes >>>> Ron suggested (2, 3, 5), but left the more substantive ones (1, 4) for >>>> Adrian to address. >>>> >>>>

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 > perspective? > > Changes include: > - mov

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

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

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. > > There is a construct where a prope

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 plan that creates a co

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 and @Jonas Devlieghere > with the CAS DWARF stuff, how are you folks > separating line table fragments for functions? My understanding was the line > table header

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

> On Jun 20, 2024, at 4:02 AM, Martin via Dwarf-discuss > wrote: > > Sorry for the late reply. I've been away. > > > - What does it mean for a property to be default? I couldn't find that > > defined in the linked FreePascal documentation. > > The property can be accessed without its name be

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

Could you send me an example .o file that reproduces the issue? I'm curious now. -- adrian > On Mar 15, 2024, at 7:41 AM, John DelSignore wrote: > > Hi Adrian, > > Thanks for the reply. As far as I can tell, neither gcc nor gfortran produce > N_SO stabs when -gdwarf-4 is used. It is the Apple

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 > wrote: >> Can you clarify what kind of information you are interested in? Are you >> talking about representing variables inside of coroutines, function pointers >>

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,