From mark@klomp.org Mon Apr 6 22:31:21 2026 From: mark@klomp.org (Mark Wielaard) Date: Tue, 7 Apr 2026 00:31:21 +0200 Subject: [Dwarf-discuss] Sourceware infrastructure updates for Q1 2026 Message-ID: <20260406223121.GQ7048@gnu.wildebeest.org> Sourceware infrastructure community updates for Q1 2026 Keep Sourceware independent, worry-free and friendly, sustain our fiscal sponsor https://sfconservancy.org/sustainer support OSUOSL to host projects like ours https://osuosl.org/donate or donate directly to Sourceware https://sourceware.org/donate.html Every quarter we provide a summary of news about Sourceware and roadmap updates https://sourceware.org/sourceware-25-roadmap.html - New buildbot CI workers and forge action runners - VM-first hardware refresh cycle completed - Forge updates - Signed-commit census leaderboard - Sourceware Organization, Contact and Open Office hours = New buildbot CI workers and forge action runners We worked with the OSUOSL admins to get a new sourceware-builder3 x86_64 server at OSUOSL 2x28 cores (2x56 threads), 768GB RAM and 2 x NVMe M.2 1TB online. It replaces two (smaller) sourceware-builder1 and sourceware-builder2 servers, which have been turned off now. The machine has been partitioned into four VMs: - sw3bb1: 40 vcpus, 256GB mem, 500GB disk - sw3bb2: 16 vcpus, 96GB mem, 420GB disk - sw3runner1: 40 vcpus, 256GB mem, 500GB disk - sw3runner2: 16 vcpus, 96GB mem, 420GB disk The buildbot worker tasks and containers can be configured through the builder project: https://sourceware.org/cgit/builder For projects with user branches (like binutils, gdb, libabigail, elfutils, valgrind) it can also be used for pre-commit CI with try branches: https://sourceware.org/binutils/wiki/Buildbot For questions please join the mailinglist: https://sourceware.org/mailman/listinfo/buildbot The forge workflows can be configured through your projects .forgejo/workflows/ actions (you can also enable actions on your personal forks). For workflows that need to run on sw3runner1 use the sourceware-large-runner label. See also the forge project on https://forge.sourceware.org/forge/ or join the mailinglist: https://sourceware.org/mailman/listinfo/forge = VM-first hardware refresh cycle completed This quarter the old server2 and server3 joined the new server1 that was moved to the new datacenter (RDU3) last quarter. They are also setup as VM-first machines (no services running on the bare-metal, everything in VMs). The intention is to configure a VM on server2 as warm backup for sourceware, periodically copying over the VM lvm snapshot. server3 will also be available for random new workloads (also VMs). As both server2 and server3 have raid6 setups we have pretty good redundancy in case of many-disk failures. The next vms would be inbox, patchwork, buildbot, bunsen (and maybe cygwin, gitweb/cgit, bugzilla, dwarfstd, valgrind). The limiting factor for creating more isolated, but publicly accessible, VMs is external IP addresses, we have 8 (which can be freely assigned to any VM on any of the 3 servers), but we are already using 4. This effort completes our bare-metal to VM-first transition. And with the replacement of the OSUOSL build servers (see above) this also completes our hardware refresh cycle. For the effort to upgrade the Sourceware hardware, services and security isolation the Sourceware PLC has been working closely together with the overseers, Software Freedom Conservancy, FSF sysadmins, Red Hat IT and OSUOSL over the last year. And thanks to your generous donations our hardware refresh fund is already back up to strenght. So we are able to replace any failing server or components (outside of waranty) with new hardware immediately. For hardware, hosting and VMs, we should be good for the next couple of years now. = Forge updates Besides the new action runners (see above), the forge now also has a bigger VM on server1 (vm02), data has been migrated from the production server still running on the RH OSPO cloud server (but needs a new resync now of course). The new VM should get an ansible setup and a hot backup on server3 (48GB mem, 16 cores, 200GB lv). There has been work/discussion on how the forge should convert a pull request to an email containing all discussions on the forge. When should it trigger? What should (and shouldn't) go into the email? Claudio has a concrete proposal for which bot workflows would need to be implemented and what should happen at what time: https://inbox.sourceware.org/c16d2000-a13c-4136-8faf-3c0bb5feb402@arm.com/ The Linaro bot does run merge requests through CI and updates comments with the current CI state. There were also suggestions to also "incoming" emails. But that still has to be setup: https://forgejo.org/docs/latest/admin/advanced/incoming-email/ = Signed-commit census leaderboard How is your project doing on signed commits? analyzing branch HEAD since 2026-01-01 cygwin-calm 28 commits 28 signed 100% 1 committers 1 signers 100% cygwin-setup 28 commits 28 signed 100% 2 committers 2 signers 100% profiledb 5 commits 5 signed 100% 1 committers 1 signers 100% annobin 10 commits 9 signed 90% 2 committers 1 signers 50% systemtap 16 commits 13 signed 81% 2 committers 2 signers 100% bunsen 57 commits 46 signed 80% 3 committers 2 signers 66% elfutils 55 commits 36 signed 65% 4 committers 3 signers 75% glibc 256 commits 19 signed 7% 24 committers 1 signers 4% gcc 2008 commits 137 signed 6% 133 committers 11 signers 8% newlib-cygwin 95 commits 2 signed 2% 7 committers 1 signers 14% binutils-gdb 1214 commits 20 signed 1% 51 committers 4 signers 7% valgrind 238 commits 1 signed 0% 7 committers 1 signers 14% builder 8 commits 0 signed 0% 1 committers 0 signers 0% debugedit 9 commits 0 signed 0% 1 committers 0 signers 0% dwz 2 commits 0 signed 0% 1 committers 0 signers 0% forge 1 commits 0 signed 0% 1 committers 0 signers 0% insight 22 commits 0 signed 0% 1 committers 0 signers 0% libabigail 7 commits 0 signed 0% 1 committers 0 signers 0% lvm2 238 commits 0 signed 0% 8 committers 0 signers 0% = Sourceware Organization, Contact and Open Office hours We can be reached through irc, email and bugzilla https://sourceware.org/mission.html#organization There is also the fediverse for announcements, notices, downtime or temporary network issues https://fosstodon.org/@sourceware Every second Friday of the month is the Sourceware Overseers Open Office hour in #overseers on irc.libera.chat from 16:00 till 17:00 UTC. Please feel free to drop by with any Sourceware service or hosting questions. Do you or your company want to sponsor Sourceware plans financially https://sourceware.org/sourceware-security-vision.html#plans donate hardware or services then contact us at sponsor@sourceware.org The PLC https://sourceware.org/mission.html#plc currently consists of 7 members. The mandatory minimum number of Members is 4. And no more than 2 Members may be Financially-Related to the same Entity. If you are interested in joining the PLC please read the https://sourceware.org/Conservancy-Sourceware-FSA.pdf Fiscal Sponsorship Agreement, the Conflict of Interest Policy https://sfconservancy.org/projects/policies/conflict-of-interest-policy.html and contact us at plc@sourceware.org. If you rather help with more technical tasks please join the overseers list: https://sourceware.org/mailman/listinfo/overseers Sourceware PLC, Frank Ch. Eigler, Ian Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, Mark J. Wielaard and Elena Zannoni From mark@klomp.org Fri Apr 17 15:47:15 2026 From: mark@klomp.org (Mark Wielaard) Date: Fri, 17 Apr 2026 17:47:15 +0200 Subject: [Dwarf-discuss] FOSSY 2026 toolchain track North America, Aug 6-9 Message-ID: <0bb611179f49c9da1e4a0470b8fa879b9b53125f.camel@klomp.org> We are excited to announce that there will be a toolchain track at FOSSY 2026 https://fossy.ca the fourth Free and Open Source Software Yearly conference. GNU Toolchain and friends meeting in Vancouver, Canada August 6-9 2026 at the University of British Columbia Talks by developers of core toolchain and developer tools. Compilers like GCC, the GNU Compiler Collection, assemblers and linkers like Binutils, debuggers and profilers like GDB, Systemtap and Valgrind, binary tools like libabigail, elfutils and GNU Poke, C libraries, like glibc and newlib and other language runtimes and utilities, including discussions of standards like ELF and DWARF. FOSSY has several tracks with talks over three days and an unconference the last day. Besides the toolchain track there are ~12 other tracks https://2026.fossy.ca/pages/tracks/ Submit a talk proposal at https://2026.fossy.ca/call-for-proposals/ by first creating a speaker profile. Talks can be long presentations (40 min), short presentations (20 min) or lightning talks (5 to 10 min). For either beginner, intermediate or advanced audiences, being oriented at developers, community, end users or business. Talks may be recorded and published after the conference, but the conference itself is in-person only (no online presentations during the conference). Talk proposals should be submitted before end of day June 1st. Accepted talks will get a confirmation before June 15th 2026. You can register for FOSSY by creating an account at https://2026.fossy.ca/account/signup Program Committee Andrea Pinski Bradley Kuhn Elena Zannoni Indu Bhagat Jose Marchesi Mark Wielaard From lists@mfriebe.de Sun Apr 19 20:03:28 2026 From: lists@mfriebe.de (Martin) Date: Sun, 19 Apr 2026 22:03:28 +0200 Subject: [Dwarf-discuss] Idea/Question: Add DW_AT_LowerBound to DW_TAG_String Message-ID: <303b865d-01ec-43d9-a3d6-0987670f3acd@mfriebe.de> A string is a sequence of chars... And usually a string allows access to those chars by index. This index can be 0 or 1 based. If a debugger is asked to evaluate "MyString[1]" this could be the first or 2nd char. It is possible to have defaults per language for this. But that is not always enough. In Pascal the index normally is 1 based. But compilers like FPC and Delphi support a directive "{$ZEROBASEDSTRINGS}" https://gitlab.com/freepascal.org/fpc/documentation/-/work_items/39484 which changes this to 0 based. It might be desire-able to add this to DWARF. Also Pascal strings (some of them) are ref-counted and have other fields (like encoding). Ref-count may be something generic (also applies to some arrays). And may therefore deserve an attribute of its own? From Todd.Allen@concurrent-rt.com Mon Apr 20 17:53:58 2026 From: Todd.Allen@concurrent-rt.com (Todd Allen) Date: Mon, 20 Apr 2026 17:53:58 +0000 Subject: [Dwarf-discuss] Idea/Question: Add DW_AT_LowerBound to DW_TAG_String In-Reply-To: <303b865d-01ec-43d9-a3d6-0987670f3acd@mfriebe.de> References: <303b865d-01ec-43d9-a3d6-0987670f3acd@mfriebe.de> Message-ID: <94f30306-851e-415b-892b-2e607ac860f7@concurrent-rt.com> Martin, The default lower bound is just a default. An array always can just specify the DW_AT_lower_bound if it differs from the language-defined default. In Ada, for example, lower bounds always are explicit. The choice of 1 as its default was a guess about what coders would be most likely to use. (And probably Ada's similarities to Pascal was a factor.) Todd On 4/19/26 14:03, Martin via Dwarf-discuss wrote: A string is a sequence of chars... And usually a string allows access to those chars by index. This index can be 0 or 1 based. If a debugger is asked to evaluate "MyString[1]" this could be the first or 2nd char. It is possible to have defaults per language for this. But that is not always enough. In Pascal the index normally is 1 based. But compilers like FPC and Delphi support a directive "{$ZEROBASEDSTRINGS}" https://gitlab.com/freepascal.org/fpc/documentation/-/work_items/39484 which changes this to 0 based. It might be desire-able to add this to DWARF. Also Pascal strings (some of them) are ref-counted and have other fields (like encoding). Ref-count may be something generic (also applies to some arrays). And may therefore deserve an attribute of its own? -- 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 ccoutant@gmail.com Mon Apr 20 19:29:46 2026 From: ccoutant@gmail.com (Cary Coutant) Date: Mon, 20 Apr 2026 12:29:46 -0700 Subject: [Dwarf-discuss] Idea/Question: Add DW_AT_LowerBound to DW_TAG_String In-Reply-To: <303b865d-01ec-43d9-a3d6-0987670f3acd@mfriebe.de> References: <303b865d-01ec-43d9-a3d6-0987670f3acd@mfriebe.de> Message-ID: > > In Pascal the index normally is 1 based. > But compilers like FPC and Delphi support a directive "{$ZEROBASEDSTRINGS}" > https://gitlab.com/freepascal.org/fpc/documentation/-/work_items/39484 > which changes this to 0 based. > It might be desire-able to add this to DWARF. You mean DW_TAG_string_type, right? This seems like a reasonable extension. We've always claimed DWARF is "descriptive, not prescriptive", meaning that if a tag or attribute makes sense in a context we don't cover in the document, it's still generally OK. In this case, the presence of a DW_AT_lower_bound attribute in a DW_TAG_string_type would have an obvious meaning, and a consumer that ignores it is no worse off than if the producer omitted it. It may not be quite as obvious as it sounds, though: DW_AT_lower_bound is currently defined only for subrange types (DW_TAG_generic_subrange and DW_TAG_subrange_type), which are used to define the bounds of each dimension of an array. Since strings are inherently one-dimensional, the use of one or more subrange tags as children of DW_TAG_string_type seems unnecessary (unless anyone is thinking of proposing multi-dimensional strings!). Given a known use case for DW_AT_lower_bound as an attribute of DW_TAG_string_type, I'd support a proposal to add it to DWARF V6. My opinion is that you should feel free to use it anyway in current versions of DWARF, as long as you have an agreement with any relevant debuggers. What about DW_AT_upper_bound? For string types, we have DW_AT_string_length, et al., but providing lower and upper bounds would be an alternate way to represent the string length. The argument for this is not as strong: if you replace DW_AT_string_length with DW_AT_upper_bound, you risk breaking some consumers. If you like, I'll file this as a new proposal (without upper bound). Also Pascal strings (some of them) are ref-counted and have other fields > (like encoding). > Ref-count may be something generic (also applies to some arrays). And > may therefore deserve an attribute of its own? With respect to ref counts, I'd like to see a more fleshed-out proposal with some background about how it could be useful to a consumer. -cary -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists@mfriebe.de Fri Apr 24 10:43:18 2026 From: lists@mfriebe.de (Martin) Date: Fri, 24 Apr 2026 12:43:18 +0200 Subject: [Dwarf-discuss] Discussion: ref counted types / string, arrays in Pascal Message-ID: Following up my other mail on strings... Here are some details on ref-counts in Pascal. Note, the compiler devs currently are adding "smart pointers" which to my understanding will introduce similar refcounts for other types. But I do not yet have details on that. The entire discussion is about "hidden" refcounts. That is refcounts not added by the user in the declaration of a type, but internally being part of the type. I.e. "COM" interfaces do NOT fall into this, as their refcount is defined as normal field in the underlying object. Currently in pascal there are Some string types like AnsiStrings. - the implement copy-on-write if the refcount is greater than 1 (and they are written to) Dynamic arrays (var-length) - the do not implement copy-on-write ref-counts are managed if the data is assigned to other vars, or passed as parameter. There are methods (uniquestring, SetLength) that return a copy with refcount = 1. In debugging, this information may be important for a user. - When values in an array are changed. (either by code that is stepped, or by modifying data via the debugger). => The user may need to know if that has side effects on other copies of an array - Debugging code that accesses a string via "PChar" (pointer to char). This bypasses copy-on-write, this easily leads to bugs, that can only be found checking the refcount - If a debugger allows to modify data in a string, then the debugger itself needs to know if that string needs to be copied For the debugger itself the information is important when - modifying data - creating instances of the data (e.g. when the user calls a function as part of inspecting values, and a string needs to be injected as argument) p lowercase('AbcDef') Requirements DWARF would need to be able to add "refcount" info to different types. To start with this is DW_TAG_string_type and DW_TAG_array_type. Other types may later be needed too. The info needs to describe - the (relative) location of the refcount - the size of the number If a debugger also should be able to modify/create/free the data, then more is needed. I would at first say a list of functions for various tasks. But in other languages they may not exist, and instead common actions could be described by other means. So the actions would need a choice of what the describe (maybe by use of different forms, maybe nested tags, with attributes?) Actions might be - creation (alloc mem) - init (after alloc mem) - inc/dec ref => those default to just modifying the field - get copy that may be modified? Additional considerations I talked about strings being passed as parameters to function (that are called by the debugger). In Pascal some function can be optimised so their string argument does not get the increment. This could be covered by either - a copy of the type, with a "no action" for the inc/dec - a flag on the variable (allowing the type to be the same, which may be desirable) From lists@mfriebe.de Fri Apr 24 10:55:00 2026 From: lists@mfriebe.de (Martin) Date: Fri, 24 Apr 2026 12:55:00 +0200 Subject: [Dwarf-discuss] Discussion: string encoding as part of the type (Pascal) Message-ID: In Pascal (free pascal) the string type (some of them) have an internal field (not accessible to user code) that stores the encoding. That can be an ASCII-page, or utf8, or raw (just bytes as they are).... For a debugger this info is useful to display the string correctly. A debugger would want to convert the string to the encoding used by the terminal before printing it). I am looking for ways how that could be encoded in DWARF? The first step would be e.g. some attributes to describe the location and size of that field. The 2nd part would be a mapping of the values in that field. That 2nd part may not need to be part of the encoded DWARF description. It could be just per language defaults (a debugger would have to know the values that each compiler may use). I.e. I am not sure, but this may be compiler rather than language dependent. Optional, compliers could add a global list of mapping to pre-defined DWARF constants. That would be some form of list with pairs of - "compiler encoding value" - DWARF constant This may affect the encoding used in the base type for the char. From lists@mfriebe.de Fri Apr 24 10:16:55 2026 From: lists@mfriebe.de (Martin) Date: Fri, 24 Apr 2026 12:16:55 +0200 Subject: [Dwarf-discuss] Idea/Question: Add DW_AT_LowerBound to DW_TAG_String In-Reply-To: References: <303b865d-01ec-43d9-a3d6-0987670f3acd@mfriebe.de> Message-ID: Thanks for the reply. I just double check something though... ZEROBASEDSTRINGS is actually not part of the type, but only govern how data of the type is accessed, while the directive is in use. Then the question would be a flag for scopes (more at the end of the mail). E.g. the compilation unit, since the inclusion of 3rd party code could mix code with different settings. However, this would be a really really minor issue. In most cases it could be a global configuration of the debugger. I answer your questions anyway, even though they may be mood. (sorry) Btw, a 2nd question. Just to confirm. DW_AT_string_length is in "elements" That is if the base type is a char of size "2 bytes", then length is in "chars" and not in "bytes"? This matters because FreePascal stores some length for 16bit string as size in bytes (but DWARF can handle that as location expression doing "div 2") On 20/04/2026 21:29, Cary Coutant wrote: > You mean DW_TAG_string_type, right? Yes > It may not be quite as obvious as it sounds, though: DW_AT_lower_bound > is currently defined only for subrange types (DW_TAG_generic_subrange > and DW_TAG_subrange_type), which are used to define the bounds of each > dimension of an array. Since strings are inherently one-dimensional, the > use of one or more subrange tags as children of DW_TAG_string_type seems > unnecessary (unless anyone is thinking of proposing multi-dimensional > strings!). Well, a single dimension array also has ONE DW_AT_lower_bound. IMHO a string is very similar to a single dimension array. The alternative would have been a new attribute. The advantage of DW_AT_lower_bound is that it could deal with any number as base. I can't see anything but 0 or 1 to be ever happen, but never say never. > What about DW_AT_upper_bound? For string types, we have > DW_AT_string_length, et al., but providing lower and upper bounds would > be an alternate way to represent the string length. The argument for > this is not as strong: if you replace DW_AT_string_length with > DW_AT_upper_bound, you risk breaking some consumers. I don't think it even needs DW_AT_upper_bound. Arrays can have: DW_AT_lower_bound + DW_AT_count Strings would have: DW_AT_lower_bound + DW_AT_string_length Though of course (never say never), someone else may think it handy to specify it as lower/upper. > If you like, I'll file this as a new proposal (without upper bound). Not sure if still needed. Where would be you stance on having a flag in the compilation unit? Though, the flag can actually change in the middle of a procedure. However I see no need to flag that. I am not even sure about the compilation unit. Because for a user then must change their watched expressions, every time the scope changes. (This isn't Dwarf related, rather an implementation matter of debuggers) i.e. watching the first char in a global variable, would need a different expression depending on the settings of the current scope. So for now, I would retract the request (for my own needs). > > With respect to ref counts, I'd like to see a more fleshed-out proposal > with some background about how it could be useful to a consumer. > Will do. From lazarus@mfriebe.de Fri Apr 24 19:58:44 2026 From: lazarus@mfriebe.de (Martin Frb) Date: Fri, 24 Apr 2026 21:58:44 +0200 Subject: [Dwarf-discuss] Additional values for DW_AT_accessibility Message-ID: <0a62a153-7e09-4930-ae0c-d61a98a92eb0@mfriebe.de> Currently there are the values DW_ACCESS_public DW_ACCESS_private DW_ACCESS_protected FreePascal has more (list at the end of mail) Could those please be added? https://www.freepascal.org/docs-html/ref/refse35.html > Private > ? All fields and methods that are in a private block, can only be > accessed in the module (i. e. unit) that contains the class definition. > ? They can be accessed from? ? ?inside the classes? methods or from > outside them (e. g. from other classes? methods) > Strict Private > ? All fields and methods that are in a strict private block, can only > be accessed from methods of the class itself. Other classes or > descendent classes (even in the? ?same unit) cannot access strict > private members. > Protected > ? Is the same as Private, except that the members of a Protected > section are also accessible to descendent types, even if they are > implemented in other? ?modules. > Strict Protected > ? Is the same as Protected, except that the members of a > Protected?section are also accessible to other classes implemented in > the same unit. Strict protected ? members are only visible to > descendent classes, not to other classes in the same unit. > Public > ? sections are always accessible. > Published > ? From a language perspective, this is the same as a Public section, > but the compiler generates also type information that is needed for > automatic streaming of? ?these classes if the compiler is in the {$M+} > state. Fields defined in a published section must be of class type. > Array properties cannot be in a published section. From woodard@redhat.com Sat Apr 25 01:17:46 2026 From: woodard@redhat.com (Ben Woodard) Date: Fri, 24 Apr 2026 18:17:46 -0700 Subject: [Dwarf-discuss] Additional values for DW_AT_accessibility In-Reply-To: <0a62a153-7e09-4930-ae0c-d61a98a92eb0@mfriebe.de> References: <0a62a153-7e09-4930-ae0c-d61a98a92eb0@mfriebe.de> Message-ID: I guess these have ABI implications as well and so they probably would need to be tracked so they would need to be available for tools like libabigail. While a tool like gdb probably wouldn?t care about the difference between ?Private? and ?Strict Private?, libabigail would need know if a member or a method changed from one to another. This would likely be more of an API level ABI change rather than a structural or calling convention change. If Cary hasn?t picked it up already, I?ll write up a super simple issue and ask him to file it. I haven?t done Pascal since Jr High but I can see how having the full range of access qualifiers defined could be important for some tools like libabigail and so I will also volunteer to champion the issue if necessary. Do you think we really need ?Published?? I can?t see any reason why that one is needed in DWARF. -ben > On Apr 24, 2026, at 1:36?PM, Martin Frb via Dwarf-discuss wrote: > > ?Currently there are the values > DW_ACCESS_public DW_ACCESS_private DW_ACCESS_protected > > FreePascal has more (list at the end of mail) > Could those please be added? > > https://www.freepascal.org/docs-html/ref/refse35.html >> Private >> All fields and methods that are in a private block, can only be accessed in the module (i. e. unit) that contains the class definition. >> They can be accessed from inside the classes? methods or from outside them (e. g. from other classes? methods) >> Strict Private >> All fields and methods that are in a strict private block, can only be accessed from methods of the class itself. Other classes or descendent classes (even in the same unit) cannot access strict private members. >> Protected >> Is the same as Private, except that the members of a Protected section are also accessible to descendent types, even if they are implemented in other modules. >> Strict Protected >> Is the same as Protected, except that the members of a Protected section are also accessible to other classes implemented in the same unit. Strict protected members are only visible to descendent classes, not to other classes in the same unit. >> Public >> sections are always accessible. >> Published >> From a language perspective, this is the same as a Public section, but the compiler generates also type information that is needed for automatic streaming of these classes if the compiler is in the {$M+} state. Fields defined in a published section must be of class type. Array properties cannot be in a published section. > > > -- > Dwarf-discuss mailing list > Dwarf-discuss@lists.dwarfstd.org > https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss > From updates@emails.luveedu.com Sat Apr 25 01:30:15 2026 From: updates@emails.luveedu.com (Luveedu Updates) Date: Sat, 25 Apr 2026 01:30:15 +0000 Subject: [Dwarf-discuss] =?utf-8?b?8J+Pg+KAjeKZgu+4jyBGQVNUIEZBU1QgRkFT?= =?utf-8?q?T=3A_Grab_1_Year_Cloud_Hosting_for_=E2=82=B9399_Before_It_Close?= =?utf-8?q?s!?= Message-ID: An HTML attachment was scrubbed... URL: From woodard@redhat.com Sat Apr 25 01:55:43 2026 From: woodard@redhat.com (Ben Woodard) Date: Fri, 24 Apr 2026 18:55:43 -0700 Subject: [Dwarf-discuss] Discussion: string encoding as part of the type (Pascal) In-Reply-To: References: Message-ID: <413BF5F2-2FAC-414E-9E09-F73AA8C66C15@redhat.com> I didn?t see a response to this and so here is my take on it. It would be a member of the structure which represents the Pascal string. That particular member would be marked DW_AT_artificial to separate it from something which is defined in the source code. I don?t know what type this would be but that would be the type of the member (a int or a enum or whatever) within the aggregate that defines the string structure. You would also give it a location just like any other member of an aggregate. The tricky part would be giving this semantic meaning in consumers. Generally within a consumer, it would have a language profile from the CU and that would encode language specific things like what to do when it sees one of these Pascal strings and it wants to display it. So you would have to teach whatever consumers you want to use, e.g. gdb, to know to look up that encoding variable within the string structure and how to use it when displaying the string. -ben > On Apr 24, 2026, at 3:55?AM, Martin via Dwarf-discuss wrote: > > ?In Pascal (free pascal) the string type (some of them) have an internal field (not accessible to user code) that stores the encoding. > > That can be an ASCII-page, or utf8, or raw (just bytes as they are).... > > For a debugger this info is useful to display the string correctly. A debugger would want to convert the string to the encoding used by the terminal before printing it). > > I am looking for ways how that could be encoded in DWARF? > > The first step would be e.g. some attributes to describe the location and size of that field. > > The 2nd part would be a mapping of the values in that field. > > That 2nd part may not need to be part of the encoded DWARF description. > It could be just per language defaults (a debugger would have to know the values that each compiler may use). > I.e. I am not sure, but this may be compiler rather than language dependent. > > Optional, compliers could add a global list of mapping to pre-defined DWARF constants. > That would be some form of list with pairs of > - "compiler encoding value" > - DWARF constant > > > This may affect the encoding used in the base type for the char. > > > -- > Dwarf-discuss mailing list > Dwarf-discuss@lists.dwarfstd.org > https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss > From dwarf@mfriebe.de Sat Apr 25 07:28:55 2026 From: dwarf@mfriebe.de (Martin) Date: Sat, 25 Apr 2026 09:28:55 +0200 Subject: [Dwarf-discuss] Additional values for DW_AT_accessibility In-Reply-To: References: <0a62a153-7e09-4930-ae0c-d61a98a92eb0@mfriebe.de> Message-ID: <81b0d3a5-63c8-43f7-9ac2-ecd6fa071446@mfriebe.de> Hi, Thanks for looking into it. On 25/04/2026 03:17, Ben Woodard wrote: > I guess these have ABI implications as well and so they probably would need to be tracked so they would need to be available for tools like libabigail. > > While a tool like gdb probably wouldn?t care about the difference between ?Private? and ?Strict Private?, libabigail would need know if a member or a method changed from one to another. This would likely be more of an API level ABI change rather than a structural or calling convention change. I am no expert on the ABI question. My involvement comes from maintaining a debugger. gdb does show the information on request (and so does "FpDebug", the debugger for which I would like to use this): ptype TFoo type = struct TFoo : public TObject { ? protected: ? ? LongInt ABC; ? private: ? ? LongInt Bar; } That is what brought my attention to the absence of them. > Do you think we really need ?Published?? I can?t see any reason why that one is needed in DWARF. As I said, not an expert on API, but from a quick Google, this is purely cosmetic. (as the documentation says, for actual access its the same as public). Tools relying on the generated RTTI don't (to my knowledge) rely on DWARF. So it would be only for a debugger to show the info as above. From dwarf@mfriebe.de Sat Apr 25 22:18:20 2026 From: dwarf@mfriebe.de (Martin) Date: Sun, 26 Apr 2026 00:18:20 +0200 Subject: [Dwarf-discuss] Extension for the new DW_TAG_property in DWARF-6 In-Reply-To: <3f0e83e0-3acd-4ac5-941c-ae1705232f35@mfriebe.de> References: <3f0e83e0-3acd-4ac5-941c-ae1705232f35@mfriebe.de> Message-ID: <44c94c9a-5aad-4aa1-a9c4-fbe75a34e3ea@mfriebe.de> Actually it can be even more complex type T1 = array [3..5, 1..2] of integer; TFoo = class private F1: T1; public property Bar: Integer read f1[4][1]; end; In this case several indices are required. Or a final address inside the array. Also: type t2 = record a,b: integer; end; T1 = array [3..5] of T2; TFoo = class private F1: T1; public property Bar: Integer read f1[4].b; end; The path can be any combination of index and fields (currently no pointer/deref). However this 2nd example is already solved as the address of "b"'s parent "T2" can be given (and the fact that it is in an array is not relevant) On 26/04/2026 00:09, Martin wrote: > I found a case that I was myself not previously aware off. > > In the below example the value is an indexed member of an array. > > program project1; > {$Mode objfpc} > type > ? T1 = array [3..5] of integer; > > ? TFoo = class > ? private > ??? F1: T1; > ? public > ??? property Bar: Integer read f1[4]; > ? end; > > > There is no DW_TAG_member or DW_TAG_variable for the single element. > DW_AT_property_forward can only link to the array itself. > > I additionally would need the index in the array. > > > I can also not use > > DW_OP_push_object_location to inquire of the location of the > property?s parent > > Since the array could be in a sub-structure, for which this would supply > the address. (So that then the address of the array itself can be > calculated). > > From lists@mfriebe.de Sat Apr 25 22:09:40 2026 From: lists@mfriebe.de (Martin) Date: Sun, 26 Apr 2026 00:09:40 +0200 Subject: [Dwarf-discuss] Extension for the new DW_TAG_property in DWARF-6 Message-ID: <3f0e83e0-3acd-4ac5-941c-ae1705232f35@mfriebe.de> I found a case that I was myself not previously aware off. In the below example the value is an indexed member of an array. program project1; {$Mode objfpc} type T1 = array [3..5] of integer; TFoo = class private F1: T1; public property Bar: Integer read f1[4]; end; There is no DW_TAG_member or DW_TAG_variable for the single element. DW_AT_property_forward can only link to the array itself. I additionally would need the index in the array. I can also not use > DW_OP_push_object_location to inquire of the location of the property?s parent Since the array could be in a sub-structure, for which this would supply the address. (So that then the address of the array itself can be calculated). From ccoutant@gmail.com Mon Apr 27 17:59:27 2026 From: ccoutant@gmail.com (Cary Coutant) Date: Mon, 27 Apr 2026 10:59:27 -0700 Subject: [Dwarf-discuss] Discussion: string encoding as part of the type (Pascal) In-Reply-To: References: Message-ID: > > In Pascal (free pascal) the string type (some of them) have an internal > field (not accessible to user code) that stores the encoding. > > That can be an ASCII-page, or utf8, or raw (just bytes as they are).... > > For a debugger this info is useful to display the string correctly. A > debugger would want to convert the string to the encoding used by the > terminal before printing it). > > I am looking for ways how that could be encoded in DWARF? > > The first step would be e.g. some attributes to describe the location > and size of that field. > For this, I'd look to the DW_AT_string_length, DW_AT_string_length_byte_size/_bit_size attributes as a model. You could add DW_AT_string_encoding which would take a location expression (with an implicit push object address) that yields the location of the encoding field, and DW_AT_string_encoding_{byte|bit}_size attributes that give the size of that field in your internal string representation. The 2nd part would be a mapping of the values in that field. > > That 2nd part may not need to be part of the encoded DWARF description. > It could be just per language defaults (a debugger would have to know > the values that each compiler may use). > I.e. I am not sure, but this may be compiler rather than language > dependent. > > Optional, compliers could add a global list of mapping to pre-defined > DWARF constants. > That would be some form of list with pairs of > - "compiler encoding value" > - DWARF constant > > > This may affect the encoding used in the base type for the char. > If different compilers use different constants, you'd have a compatibility problem. On the other hand, if this is a language extension, then maybe you don't expect it to be interoperable across different compilers (and indeed the internal structures of the string type may differ as well). I'd be tempted to leave this as a job for the debugger, but if you wanted to try to map the compiler's encoding values onto DWARF encoding constants (DW_ATE_*), you could have a DW_TAG_string_encoding_map DIE in the compilation unit. This could either take a single attribute with a block-form value containing your list of pairs, or it could have multiple children, each with two attributes that give the compiler's encoding value and the equivalent DW_ATE_ constant, respectively. The DW_TAG_string_type DIE has a DW_AT_type attribute that gives the type and encoding of the characters in the string. For strings where the encoding is dynamic, you might also want to invent a new DW_ATE_dynamic or DW_ATE_none encoding value, or use DW_ATE_unsigned_char, or just omit the DW_AT_type altogether. If this is a compiler extension, I'd suggest you use DWARF extensions for this information. If it's part of the language standard, feel free to follow up with a proposal along these lines. -cary -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark@klomp.org Mon Apr 27 21:44:01 2026 From: mark@klomp.org (Mark Wielaard) Date: Mon, 27 Apr 2026 23:44:01 +0200 Subject: [Dwarf-discuss] FOSSY 2026 toolchain track North America, Aug 6-9 In-Reply-To: <0bb611179f49c9da1e4a0470b8fa879b9b53125f.camel@klomp.org> References: <0bb611179f49c9da1e4a0470b8fa879b9b53125f.camel@klomp.org> Message-ID: <20260427214401.GF11304@gnu.wildebeest.org> Please find attached the generic FOSSY call for participation with more details about the conference and how to submit talk proposals. https://sfconservancy.org/news/2026/apr/23/fossy26-cfp/ Note that the official call for participation has a deadline that is one week earlier than the toolchain track one. Although we will accept talk proposals up to June 1st, please try to submit by May 22 if possible. That will make coordination with other FOSSY tracks easier for the program committee. See also https://gcc.gnu.org/wiki/fossy2026 On Fri, Apr 17, 2026 at 05:47:15PM +0200, Mark Wielaard wrote: > We are excited to announce that there will be a toolchain track at > FOSSY 2026 https://fossy.ca the fourth Free and Open Source Software > Yearly conference. > > GNU Toolchain and friends meeting in Vancouver, Canada > August 6-9 2026 at the University of British Columbia > > Talks by developers of core toolchain and developer tools. Compilers > like GCC, the GNU Compiler Collection, assemblers and linkers like > Binutils, debuggers and profilers like GDB, Systemtap and Valgrind, > binary tools like libabigail, elfutils and GNU Poke, C libraries, > like glibc and newlib and other language runtimes and utilities, > including discussions of standards like ELF and DWARF. > > FOSSY has several tracks with talks over three days and an > unconference the last day. Besides the toolchain track there > are ~12 other tracks https://2026.fossy.ca/pages/tracks/ > > Submit a talk proposal at https://2026.fossy.ca/call-for-proposals/ > by first creating a speaker profile. > > Talks can be long presentations (40 min), short presentations (20 min) > or lightning talks (5 to 10 min). For either beginner, intermediate or > advanced audiences, being oriented at developers, community, end users > or business. > > Talks may be recorded and published after the conference, but the > conference itself is in-person only (no online presentations during > the conference). > > Talk proposals should be submitted before end of day June 1st. > Accepted talks will get a confirmation before June 15th 2026. > > You can register for FOSSY by creating an account at > https://2026.fossy.ca/account/signup > > Program Committee > > Andrea Pinski > Bradley Kuhn > Elena Zannoni > Indu Bhagat > Jose Marchesi > Mark Wielaard -------------- next part -------------- An embedded message was scrubbed... From: Software Freedom Conservancy Subject: Submit your #FOSSY26 talk proposals by May 22 Date: Thu, 23 Apr 2026 13:16:36 -0700 Size: 6520 URL: From woodard@redhat.com Tue Apr 28 17:17:29 2026 From: woodard@redhat.com (Ben Woodard) Date: Tue, 28 Apr 2026 10:17:29 -0700 Subject: [Dwarf-discuss] Additional values for DW_AT_accessibility In-Reply-To: <81b0d3a5-63c8-43f7-9ac2-ecd6fa071446@mfriebe.de> References: <0a62a153-7e09-4930-ae0c-d61a98a92eb0@mfriebe.de> <81b0d3a5-63c8-43f7-9ac2-ecd6fa071446@mfriebe.de> Message-ID: <056427ae-bb53-42cc-9a0c-acb05c2946ca@redhat.com> On 4/25/26 12:28 AM, Martin via Dwarf-discuss wrote: > Hi, > > Thanks for looking into it. > > On 25/04/2026 03:17, Ben Woodard wrote: >> I guess these have ABI implications as well and so they probably >> would need to be tracked so they would need to be available for tools >> like libabigail. >> >> While a tool like gdb probably wouldn?t care about the difference >> between ?Private? and ?Strict Private?, libabigail would need know if >> a member or a method changed from one to another. This would likely >> be more of an API level ABI change rather than a structural or >> calling convention change. > > I am no expert on the ABI question. My involvement comes from > maintaining a debugger. > > gdb does show the information on request (and so does "FpDebug", the > debugger for which I would like to use this): > > ptype TFoo > type = struct TFoo : public TObject { > ? protected: > ? ? LongInt ABC; > ? private: > ? ? LongInt Bar; > } > > That is what brought my attention to the absence of them. > > >> Do you think we really need ?Published?? I can?t see any reason why >> that one is needed in DWARF. > > As I said, not an expert on API, but from a quick Google, this is > purely cosmetic. (as the documentation says, for actual access its the > same as public). > The ABI thing would come up if you wanted an ABI checker like libabigail to be able to detect when a particular member changes from: Private to Strict Private. That changes the API of the interface and consequently changes the ABI of the resulting object. It doesn't at all change the calling convention. Anyway, I'll file the DWARF Issue for you. Then the Chair will assign it an issue. It doesn't sound very controversial. -ben > Tools relying on the generated RTTI don't (to my knowledge) rely on > DWARF. So it would be only for a debugger to show the info as above. > From dwarf@mfriebe.de Tue Apr 28 20:42:01 2026 From: dwarf@mfriebe.de (Martin) Date: Tue, 28 Apr 2026 22:42:01 +0200 Subject: [Dwarf-discuss] Possible mistakes in DWARF-6 Draft for properties (differences to issue in tracker) Message-ID: The issue for the property addition: https://dwarfstd.org/issues/240507.1.html > DW_TAG_property > DW_AT_name "Indexed" > > DW_TAG_property_getter > DW_AT_property_forward > > DW_TAG_formal_parameter ; _this (no default specified, details inherited from GetValue > DW_TAG_formal_parameter ; x (no default specified) > DW_TAG_formal_parameter > DW_AT_default_value ; property index formal-param are direct child entities of DW_TAG_property_getter But in dwarf6-20260411-0357.pdf D.19 Property Example Page 405 > ! Indexed property > ! > private > function GetValue ( x : word ; AIndex : Integer ) : char ; > public > property Indexed [ x : word ]: char index 1 read GetValue ; Is give as follows. But the formal parameters (for the default value) must be in the DW_TAG_property_getter. The "function GetValue" (if called/used without the property) does not have a default value. Only when called by/via the property does the default value exist (from the specified "index 1" in the property declaration. (Of course the subprogram needs param declarations. But without default) > ! > ! Indexed property > ! > DW_TAG_subprogram ! function GetValue > DW_AT_accessibility(DW_ACCESS_private) > DW_AT_name("GetValue") ! (x: word; AIndex: Integer): char; > DW_AT_type(ref to char) > DW_TAG_formal_parameter ! implicit _this > DW_TAG_formal_parameter ! x (no default specified) > DW_TAG_formal_parameter ! AIndex > DW_AT_default_value ! > DW_OP_lit1 ! default index =1 > ... > DW_TAG_property ! property Indexed[x: word]: char index 1 > DW_AT_accessibility(DW_ACCESS_public) > DW_AT_name("Indexed") > DW_TAG_property_getter ! read GetValue; > DW_AT_property_forward(ref to GetValue) Also in the same example, just a bit above - DW_AT_name is to little indented > DW_TAG_property ! property PropFromMethods: integer > DW_AT_accessibility(DW_ACCESS_public) > DW_AT_name("PropFromMethods") > DW_TAG_property_getter ! read GetProp > DW_AT_property_forward(ref to GetProp) > DW_TAG_property_setter ! write SetProp; > DW_AT_property_forward(ref to SetProp)