From khuey@pernos.co Tue Oct 1 15:42:00 2024 From: khuey@pernos.co (Kyle Huey) Date: Tue, 1 Oct 2024 08:42:00 -0700 Subject: [Dwarf-discuss] Coroutines In-Reply-To: <0562EA8A-7FE5-43BD-A036-49D615D6C9B1@apple.com> References: <880F4D0D-9D73-4584-8101-3080410A8495@apple.com> <77B75B17-F11A-4F06-AD67-1D857F30C6B9@apple.com> <0562EA8A-7FE5-43BD-A036-49D615D6C9B1@apple.com> Message-ID: On Wed, Feb 28, 2024 at 10:02?AM Adrian Prantl wrote: > LLDB implements this in a custom stepping plan that creates a conditional breakpoint where two async contexts are compared: First, there's the active async context at the time of the step. Next, the active async context at the time the breakpoint is hit. If the two async contexts are equal, then the breakpoint is discarded and the step has completed. Out of curiosity where does this code actually live? - Kyle From aprantl@apple.com Tue Oct 1 16:41:33 2024 From: aprantl@apple.com (Adrian Prantl) Date: Tue, 01 Oct 2024 09:41:33 -0700 Subject: [Dwarf-discuss] Coroutines In-Reply-To: References: <880F4D0D-9D73-4584-8101-3080410A8495@apple.com> <77B75B17-F11A-4F06-AD67-1D857F30C6B9@apple.com> <0562EA8A-7FE5-43BD-A036-49D615D6C9B1@apple.com> Message-ID: 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 conditional breakpoint where two async contexts are compared: First, there's the active async context at the time of the step. Next, the active async context at the time the breakpoint is hit. If the two async contexts are equal, then the breakpoint is discarded and the step has completed. > > Out of curiosity where does this code actually live? > > - Kyle From ccoutant@gmail.com Tue Oct 1 23:04:37 2024 From: ccoutant@gmail.com (Cary Coutant) Date: Tue, 1 Oct 2024 16:04:37 -0700 Subject: [Dwarf-discuss] Proposal: `DW_LNS_indirect_line` In-Reply-To: References: <8d642490-9501-47eb-90f8-6e34f7196ecc@mlugg.co.uk> Message-ID: The DWARF committee has voted to reject this proposal for DWARF 6. The committee felt that the cost of updating line numbers without the proposed indirection was not clearly shown to be unreasonable. We would be willing to reconsider the proposal at a later date if implementation experience shows it to be worthwhile. This could be prototyped as a producer extension by using extended line table opcodes to build the `indirect_lines` table (in the same way that `DW_LNE_define_file` could be used in DWARF 4 to build the `file_names` table), or by splitting the indirect table into a separate section. In any case, it was suggested that `DW_LNS_indirect_line` should be an extended opcode, as its use is not expected to be common enough (across all use cases) to warrant a standard opcode. -cary On Mon, Jul 1, 2024 at 7:56?PM Cary Coutant wrote: > Added as Issue 240626.1 . > > -cary > > > On Wed, Jun 26, 2024 at 4:06?PM Matthew Lugg via Dwarf-discuss < > dwarf-discuss@lists.dwarfstd.org> wrote: > >> # Add DW_LNS_indirect_line - update `line` to absolute value stored >> indirectly >> >> ## Background >> >> In many source languages, it is possible for many program-counter >> addresses with arbitrary >> separation to correspond to the same source line due to features like >> templates/generics. When >> designing an incremental compiler, the line number program must be >> updated when line numbers within >> a source file are moved. It would be desirable to have the property that >> when moving a source line >> corresponding to a large amount of distinct program-counter addresses, >> only one line number value in >> the DWARF information needs to be updated. For this to be true, the >> regions of the line number >> program corresponding to each such address must include the line number >> of the source construct not >> directly, but through an indirect reference. This allows one line number >> value stored in the binary >> to be shared across arbitrarily many entries in the line number matrix. >> >> This is not currently possible: all modifications to the `line` register >> are given by relative >> offsets, and all of these offsets are directly included in the >> instruction (or implicit in the case >> of a special opcode). >> >> ## Overview >> >> Introduce new fields to the line number program header, >> `indirect_lines_length` (ULEB128) and >> `indirect_lines` (opaque block of bytes containing ULEB128 values). The >> `indirect_lines_length` >> field is the length in bytes of the `indirect_lines` section, rather >> than the number of elements. >> Introduce a new standard opcode to the line number program, >> `DW_LNS_indirect_line`. This opcode >> takes a single ULEB128 operand, which represents a byte offset into the >> `indirect_lines` stored in >> the header. The effect of this instruction is to set the `line` register >> to the ULEB128 value stored >> at the given byte offset into `indirect_lines`. Note that >> `indirect_lines` is not itself validated >> to be a valid sequence of ULEB128 values; decoding only occurs when >> `DW_LNS_indirect_line` is used. >> This allows an incremental compiler to pre-allocate a large amount of >> padding space in >> `indirect_lines` to fill in later as needed. >> >> Note that an incremental compiler would not necessarily wish to use >> variable-length integers to >> represent this information, since certain changes of line numbers could >> cause a line number which >> was previously encoded using 1 byte to now require 2. However, since the >> stored values need not be >> densely packed, an implementation is free to reserve as much space as is >> necessary for each entry. >> For instance, the downstream Zig compiler (which is the original >> motivator for this proposal) may >> choose to reserve 4 or 5 bytes for each line number, as line numbers in >> Zig source files cannot >> exceed 1<<32. The use of ULEB128 allows the compiler to make an >> appropriate decision here instead of >> codifying such a restriction into the DWARF specification. >> >> ## Proposed Changes >> >> Pages and line numbers are given for the 2024-06-16 working draft of >> DWARF Version 6, which is the >> latest draft at the time of writing. >> >> 6.2.4 (pg 163; line 27) >> >> 21. indirect_lines_length (ULEB128) >> The length in bytes of the data stored in the `indirect_lines` field. >> 22. indirect_lines (block containing ULEB128 entries) >> A collection of line numbers, each stored as a ULEB128 integer. >> These values are referenced by >> DW_LNS_indirect_line instructions to modify the state of the line >> number information state >> machine. >> >> The data stored in this field is not checked to be a valid sequence >> of ULEB128 entries. The >> contained data may include padding bytes or otherwise invalid data. >> As such, it is expected that >> bytes of this field be accessed only when a DW_LNS_indirect_line >> instruction references them. >> >> 6.2.5.2 (pg 170; line 23) >> >> 14. DW_LNS_indirect_line >> The DW_LNS_indirect_line opcode takes a single unsigned LEB128 >> operand. This operand is >> interpreted as a byte offset into the `indirect_lines` field of the >> line number program header. >> An unsigned LEB128 value is read from `indirect_lines` at the given >> offset, and this value is >> stored into the state machine's `line` register. >> >> 7.22 (pg 246; table 7.25) >> >> Opcode name | Value >> ----------------------+------- >> ... | ... >> DW_LNS_indirect_line | 0x0d >> >> -- >> Dwarf-discuss mailing list >> Dwarf-discuss@lists.dwarfstd.org >> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From augusto2112@icloud.com Fri Oct 4 19:56:41 2024 From: augusto2112@icloud.com (Augusto Noronha) Date: Fri, 4 Oct 2024 12:56:41 -0700 Subject: [Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties) Message-ID: <1737CB9E-2917-47B5-AB8C-4F8CF3A7ABD4@icloud.com> Hi Martin, Could you explain what a Pascal-style stored accessor is or link to a reference to it? I tried looking it up but couldn?t find anything relevant. I think the proposal should probably expand on that a bit. Thank you, Augusto > On Oct 1, 2024, at 5:01?AM, dwarf-discuss-request@lists.dwarfstd.org wrote: > > Re: Proposal: Add support for "property" with getter/setter > (based on Pascal properties) From lists@mfriebe.de Mon Oct 7 09:23:27 2024 From: lists@mfriebe.de (Martin) Date: Mon, 7 Oct 2024 11:23:27 +0200 Subject: [Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties) In-Reply-To: <1737CB9E-2917-47B5-AB8C-4F8CF3A7ABD4@icloud.com> References: <1737CB9E-2917-47B5-AB8C-4F8CF3A7ABD4@icloud.com> Message-ID: <7d42b467-7ec8-4c13-9b22-a33e0f7237f9@mfriebe.de> On 04/10/2024 21:56, Augusto Noronha via Dwarf-discuss wrote: > Hi Martin, > > Could you explain what a Pascal-style stored accessor is or link to a reference to it? I tried looking it up but couldn?t find anything relevant. > https://www.freepascal.org/docs-html/ref/refsu38.html FreePascal and Delphi have RTTI, which allows accessing data. One use case is streaming of a class (well the published part of it). This is for example used for GUI apps where the properties of a designed GUI (form, buttons, ..) are streamed so the runtime can load them. But also ORM libs make use of it, or REST. For classes there is a "published" section (public + RTTI). It can contain fields and properties. And any code, without knowledge of the class, can read those fields. In some scenarios it is not needed to stream properties if they have there default value. So the streaming code needs to access that. property Foo: integer read GetFoo write SetFoo stored ShouldStoreFoo default 123; default takes a value (and exists only for certain data types like integer properties. It is stored in the RTTI. Stored can be a function or field (or constant) of boolean type. The RTTI also has a link to it, so the streaming code can call it. Stored = true => the property should be stored in the stream Stored = false -> the property should not be stored From anoronha@apple.com Mon Oct 7 20:40:09 2024 From: anoronha@apple.com (Augusto Noronha) Date: Mon, 07 Oct 2024 13:40:09 -0700 Subject: [Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties) In-Reply-To: <7d42b467-7ec8-4c13-9b22-a33e0f7237f9@mfriebe.de> References: <1737CB9E-2917-47B5-AB8C-4F8CF3A7ABD4@icloud.com> <7d42b467-7ec8-4c13-9b22-a33e0f7237f9@mfriebe.de> Message-ID: > FreePascal and Delphi have RTTI, which allows accessing data. One use case is streaming of a class (well the published part of it). > This is for example used for GUI apps where the properties of a designed GUI (form, buttons, ..) are streamed so the runtime can load them. But also ORM libs make use of it, or REST. > For classes there is a "published" section (public + RTTI). > It can contain fields and properties. > And any code, without knowledge of the class, can read those fields. > In some scenarios it is not needed to stream properties if they have there default value. So the streaming code needs to access that. > property Foo: integer read GetFoo write SetFoo stored ShouldStoreFoo default 123; > default takes a value (and exists only for certain data types like integer properties. It is stored in the RTTI. > Stored can be a function or field (or constant) of boolean type. The RTTI also has a link to it, so the streaming code can call it. > Stored = true => the property should be stored in the stream > Stored = false -> the property should not be stored Thanks for the clarification Martin. Streaming as a language construct (and controlling whether a property should be streamable or not) seems like a pretty Pascal specific feature, maybe this could be a Pascal extension? > On Oct 7, 2024, at 2:23?AM, Martin via Dwarf-discuss wrote: > > On 04/10/2024 21:56, Augusto Noronha via Dwarf-discuss wrote: >> Hi Martin, >> Could you explain what a Pascal-style stored accessor is or link to a reference to it? I tried looking it up but couldn?t find anything relevant. > > https://www.freepascal.org/docs-html/ref/refsu38.html > > -- > Dwarf-discuss mailing list > Dwarf-discuss@lists.dwarfstd.org > https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss From anoronha@apple.com Mon Oct 7 20:40:09 2024 From: anoronha@apple.com (Augusto Noronha) Date: Mon, 07 Oct 2024 13:40:09 -0700 Subject: [Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties) In-Reply-To: <7d42b467-7ec8-4c13-9b22-a33e0f7237f9@mfriebe.de> References: <1737CB9E-2917-47B5-AB8C-4F8CF3A7ABD4@icloud.com> <7d42b467-7ec8-4c13-9b22-a33e0f7237f9@mfriebe.de> Message-ID: > FreePascal and Delphi have RTTI, which allows accessing data. One use case is streaming of a class (well the published part of it). > This is for example used for GUI apps where the properties of a designed GUI (form, buttons, ..) are streamed so the runtime can load them. But also ORM libs make use of it, or REST. > For classes there is a "published" section (public + RTTI). > It can contain fields and properties. > And any code, without knowledge of the class, can read those fields. > In some scenarios it is not needed to stream properties if they have there default value. So the streaming code needs to access that. > property Foo: integer read GetFoo write SetFoo stored ShouldStoreFoo default 123; > default takes a value (and exists only for certain data types like integer properties. It is stored in the RTTI. > Stored can be a function or field (or constant) of boolean type. The RTTI also has a link to it, so the streaming code can call it. > Stored = true => the property should be stored in the stream > Stored = false -> the property should not be stored Thanks for the clarification Martin. Streaming as a language construct (and controlling whether a property should be streamable or not) seems like a pretty Pascal specific feature, maybe this could be a Pascal extension? > On Oct 7, 2024, at 2:23?AM, Martin via Dwarf-discuss wrote: > > On 04/10/2024 21:56, Augusto Noronha via Dwarf-discuss wrote: >> Hi Martin, >> Could you explain what a Pascal-style stored accessor is or link to a reference to it? I tried looking it up but couldn?t find anything relevant. > > https://www.freepascal.org/docs-html/ref/refsu38.html > > -- > Dwarf-discuss mailing list > Dwarf-discuss@lists.dwarfstd.org > https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss From lists@mfriebe.de Mon Oct 7 21:39:06 2024 From: lists@mfriebe.de (Martin) Date: Mon, 7 Oct 2024 23:39:06 +0200 Subject: [Dwarf-discuss] Proposal: Add support for "property" with getter/setter (based on Pascal properties) In-Reply-To: References: <1737CB9E-2917-47B5-AB8C-4F8CF3A7ABD4@icloud.com> <7d42b467-7ec8-4c13-9b22-a33e0f7237f9@mfriebe.de> Message-ID: <48db364e-b347-4aac-bcd4-27339fe7bb39@mfriebe.de> On 07/10/2024 22:40, Augusto Noronha wrote: > > Streaming as a language construct (and controlling whether a property should be streamable or not) seems like a pretty Pascal specific feature, maybe this could be a Pascal extension? Or probably be moved to RTTI, of which I have not yet evaluated if it needs special DWARF support. RTTI seems to exist in C++, but I haven't used it there myself. Also RTTI is in the end a structure of its own, and the most that DWARF may need if at all would be a pointer to it, but even that could be an artificial field. "stored" only has a language constructs for defining it. Calling it is done via the fields in RTTI. So, yes. "stored" can be dropped. > > >> On Oct 7, 2024, at 2:23?AM, Martin via Dwarf-discuss wrote: >> >> On 04/10/2024 21:56, Augusto Noronha via Dwarf-discuss wrote: >>> Hi Martin, >>> Could you explain what a Pascal-style stored accessor is or link to a reference to it? I tried looking it up but couldn?t find anything relevant. >> I may just have done above. There is a hidden field in the class that points to RTTI. And in RTTI there is a field "pointer to function". So you would actually not find any code that directly calls that function (via any language construct). I initially went only through how the property is defined, not how it is used. From khuey@pernos.co Wed Oct 9 14:40:03 2024 From: khuey@pernos.co (Kyle Huey) Date: Wed, 9 Oct 2024 07:40:03 -0700 Subject: [Dwarf-discuss] Coroutines In-Reply-To: References: <880F4D0D-9D73-4584-8101-3080410A8495@apple.com> <77B75B17-F11A-4F06-AD67-1D857F30C6B9@apple.com> <0562EA8A-7FE5-43BD-A036-49D615D6C9B1@apple.com> Message-ID: Hi Felipe, Any chance you could point me in the right direction? - Kyle On Tue, Oct 1, 2024 at 9:41?AM Adrian Prantl wrote: > > 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 conditional breakpoint where two async contexts are compared: First, there's the active async context at the time of the step. Next, the active async context at the time the breakpoint is hit. If the two async contexts are equal, then the breakpoint is discarded and the step has completed. > > > > Out of curiosity where does this code actually live? > > > > - Kyle > From aburgess@redhat.com Thu Oct 10 10:27:57 2024 From: aburgess@redhat.com (Andrew Burgess) Date: Thu, 10 Oct 2024 11:27:57 +0100 Subject: [Dwarf-discuss] Request for clarification w.r.t. DW_AT_entry_pc Message-ID: <878quwb6c2.fsf@redhat.com> I'd like to ask for some clarification relating to DW_AT_entry_pc. Here is the relevant section from the DWARF-5 spec for reference: 2.18 Entry Address The entry or first executable instruction generated for an entity, if applicable, is often the lowest addressed instruction of a contiguous range of instructions. In other cases, the entry address needs to be specified explicitly. Any debugging information entry describing an entity that has a range of code addresses, which includes compilation units, module initialization, subroutines, lexical blocks, try/catch blocks, and the like, may have a DW_AT_entry_pc attribute to indicate the entry address which is the address of the instruction where execution begins within that range of addresses. If the value of the DW_AT_entry_pc attribute is of class address that address is the entry address; or, if it is of class constant, the value is an unsigned integer offset which, when added to the base address of the function, gives the entry address. If no DW_AT_entry_pc attribute is present, then the entry address is assumed to be the same as the base address of the containing scope. I am slightly confused by two parts of this. First, this: "...if it is of class constant, the value is an unsigned integer offset which, when added to the base address of the function, gives the entry address." What does 'of the function' mean in this context? I wonder if this possibly means the base address of the DIE which contains the DW_AT_entry_pc itself? Or should I be looking up the DIE hierarchy some specific DIE type? Next this: "If no DW_AT_entry_pc attribute is present, then the entry address is assumed to be the same as the base address of the containing scope." My very literal reading of this is that "containing scope" must be the DIE which contains the DIE which is missing the DW_AT_entry_pc, i.e. the parent of the DIE we are currently looking at. I got there because DW_AT_entry_pc is missing, so nothing contains it. Therefore the only thing that can be contained is the DIE we are currently considering. However, I suspect this might not be the intended meaning. My less literal interpretation is that we should use the base address of the DIE which is missing the DW_AT_entry_pc. Any guidance is gratefully received. Thanks, Andrew