From mark@klomp.org Mon Jun 5 09:22:39 2023 From: mark@klomp.org (Mark Wielaard) Date: Mon, 5 Jun 2023 11:22:39 +0200 Subject: [Dwarf-discuss] Sourceware infrastructure updates for Q2 2023 Message-ID: <20230605092239.GZ16634@gnu.wildebeest.org> Sourceware infrastructure community updates for Q2 2023 - https://dwarfstd.org/ joins Sourceware - https://snapshots.sourceware.org/ - Simpler b4 setup - Sourceware joins Software Freedom Conservancy - Sourceware joins the fediverse @sourceware@fosstodon.org - Mirrors and Software Heritage - Open Office Hours (this Friday) = dwarfstd.org joins Sourceware The DWARF Debugging Standard, are now hosted on Sourceware. This includes git.dwarfstd.org, wiki.dwarfstd.org and lists.dwarfstd.org. Sourceware already hosted the old dwarf2 archives https://sourceware.org/legacy-ml/dwarf2/ = snapshots.sourceware.org Thanks to OSUOSL we now have a snapshots server to publish static artifacts from current git repos created in isolated containers. It can be used as alternative to git hooks or cron jobs to generate snapshots for things like: GNU poke code and doc snapshots: https://snapshots.sourceware.org/gnupoke/trunk/latest/ elfutils code coverage: https://snapshots.sourceware.org/elfutils/coverage/latest/ libabigail website, manuals and api docs: https://snapshots.sourceware.org/libabigail/html-doc/latest/ valgrind snapshots and manuals: https://snapshots.sourceware.org/valgrind/trunk/latest/ DWARF draft spec: https://snapshots.sourceware.org/dwarfstd/dwarf-spec/latest/ The container files and build steps are defined through the builder project. https://inbox.sourceware.org/20230409113050.GA6496@gnu.wildebeest.org = Simpler b4 setup Previously the guidance for adding b4 support through inbox.sourceware.org was to add per project mailing-list b4 settings. But if all your projects have an inbox.sourceware.org mailinglist you can simply use: $ git config --global b4.midmask https://inbox.sourceware.org/%s $ git config --global b4.linkmask https://inbox.sourceware.org/%s Since public-inbox knows about all message-ids independent of which mailinglist they were posted in and b4 just needs the message-id. Thanks to Thomas Schwinge for the hint. = Sourceware joins Software Freedom Conservancy https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/ As the fiscal host of Sourceware, Software Freedom Conservancy will provide a home for fundraising, legal protection and governance that will benefit all projects under Sourceware's care. We share one mission: developing, distributing and advocating for Software Freedom. Together we will offer a worry-free, friendly home for core toolchain and developer tool projects. There will be no big changes, this is just an oppertunity to protect the confidence in the long term future of Sourceware. There is a small budget already available which we would like to use for extra redundancy and backup services. But we are happy to discuss other ideas like mentioned in the original proposal and Sourceware technical roadmap. https://inbox.sourceware.org/Yw5Q4b%2F2nqvAi3K4@elastic.org/ https://inbox.sourceware.org/YrLdfDWzq1T4k5xg@wildebeest.org/ = Sourceware joins the fediverse Sourceware joined the fediverse at @sourceware@fosstodon.org https://fosstodon.org/@sourceware The account will be used for Sourceware announcements, notices about downtime and temporary issues with our network. = Mirrors and Software Heritage We added two rsync and http mirrors in China https://sourceware.org/mirrors.html And the Software Heritage project https://www.softwareheritage.org/ started archiving the active git repos. We are working on also adding the (historic) subversion and cvs archives. This is in addition to the mirrors at SourceHut https://sr.ht/~sourceware/ Thanks to Paul Wise for getting the ball rolling. https://sourceware.org/bugzilla/show_bug.cgi?id=29618 = Overseers Open Office hours Every second Friday of the month is the Overseers Open Office hour in #overseers on irc.libera.chat from 18:00 till 19:00 UTC. That is this Friday June 9th. Of course you are welcome to drop into the #overseers channel at any time and we can also be reached through email and bugzilla: https://sourceware.org/mission.html#organization If you aren't already and want to keep up to date on Sourceware infrastructure services then please also subscribe to the overseers mailinglist. https://sourceware.org/mailman/listinfo/overseers From ardovm@10dic16.it Mon Jun 5 09:40:16 2023 From: ardovm@10dic16.it (Arrigo Marchiori) Date: Mon, 5 Jun 2023 11:40:16 +0200 Subject: [Dwarf-discuss] Other - Broken link on dwarfstd.org homepage Message-ID: Dear All, the dwarfstd.org homepage, under "DWARF Introduction", contains a broken link labeled "Introduction to the DWARF Debugging Format". The link points to: https://dwarfstd.org/doc/Debugging-using-DWARF-2012.pdf and opens a "Not found" error page. Best regards, -- Arrigo From mark@klomp.org Mon Jun 5 11:24:31 2023 From: mark@klomp.org (Mark Wielaard) Date: Mon, 05 Jun 2023 13:24:31 +0200 Subject: [Dwarf-discuss] Other - Broken link on dwarfstd.org homepage In-Reply-To: References: Message-ID: Hi Arrigo, On Mon, 2023-06-05 at 11:40 +0200, Arrigo Marchiori via Dwarf-discuss wrote: > the dwarfstd.org homepage, under "DWARF Introduction", contains a > broken link labeled "Introduction to the DWARF Debugging Format". > > The link points to: > https://dwarfstd.org/doc/Debugging-using-DWARF-2012.pdf > and opens a "Not found" error page. The original file had spaces in the name. I added a Debugging-using- DWARF-2012.pdf -> 'Debugging using DWARF-2012.pdf' symlink. Now it should work again. Cheers, Mark From ccoutant@gmail.com Mon Jun 5 19:43:30 2023 From: ccoutant@gmail.com (Cary Coutant) Date: Mon, 5 Jun 2023 12:43:30 -0700 Subject: [Dwarf-discuss] Other - Broken link on dwarfstd.org homepage In-Reply-To: References: Message-ID: > > the dwarfstd.org homepage, under "DWARF Introduction", contains a > > broken link labeled "Introduction to the DWARF Debugging Format". > > > > The link points to: > > https://dwarfstd.org/doc/Debugging-using-DWARF-2012.pdf > > and opens a "Not found" error page. > > The original file had spaces in the name. I added a Debugging-using- > DWARF-2012.pdf -> 'Debugging using DWARF-2012.pdf' symlink. I've fixed the original link. -cary From woodard@redhat.com Wed Jun 7 22:09:55 2023 From: woodard@redhat.com (Ben Woodard) Date: Wed, 7 Jun 2023 15:09:55 -0700 Subject: [Dwarf-discuss] ISSUE: tensor types. V4 In-Reply-To: References: <409efa13-667f-886e-1089-8b8ff283aff3@palves.net> <3e58b9c6-2b34-7328-4d1c-e1c8cf8ac66a@palves.net> <4e01b593-f5ef-f962-6e7c-072281f88154@redhat.com> <9c79cf89-8d75-c7cc-02ec-049478138a01@concurrent-rt.com> <2a17fb7f-d37c-0c9a-b22a-31e5d933cfda@concurrent-rt.com> Message-ID: <6189b861-8320-f9af-884e-03e6c5663302@redhat.com> This is my long overdue revision my vector types proposal. The main difference is Todd Allen and Markus Metzger together convinced me that adding flavors to the tensor attributes were not needed. It should replace the current proposal https://dwarfstd.org/issues/230413.1.html Tensor types Some compilers support vector data types, which are not possible to represent today in standard DWARF.? A vector is an array of values. These can be allocated to a SIMD vector register, if available, either permanently or temporarily, and operations on vectors make use of SIMD instructions, again if available. For example, as an extension to C and C++, GCC supports defining vector data types as described here: ? https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html In this C/C++ extension, vector types are similar to arrays, and you can index and initialize them similarly, but they have some important differences.? For example: - C arrays automatically decay to pointers.? Vector types do not. - Vector types can be passed by value to functions, and likewise ? functions can return vector types by value. Neither of which can be ? done with C arrays. - Vector types can be used with a subset of normal C operations: +, -, ? *, /, unary minus, ^, |, &, ~, %.? For example, addition is defined as ? the addition of the corresponding elements of the operands. A debugger that supports C/C++ expression evaluation will want to be able to support these vector operations on vector objects too. Vector types appear on function prototypes, so they have their own mangling scheme in the Itanium ABI. To distinguish these vector types from regular C arrays, GCC's DWARF describes a vector type as an array with the DW_AT_GNU_vector attribute. Other languages have support for vector types, with similar ABI and/or API implications, and so DW_AT_GNU_vector is also used for languages beyond C/C++ today. Support for this DWARF extension has been implemented in GDB for well over a decade. Other vendor's compilers have similar C/C++ extensions.? For example, Motorola?s Altivec C/C++ Language Extensions, which predates GCC's extensions. Clang also supports the GCC vector extensions, and in some cases describes the vector types in DWARF using the same attribute as GCC. However, clang also supports many other types of vectors with somewhat different semantics than those used by GCC. https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors In the process of refining this proposal, we debated whether this proposal should be a tag like DW_TAG_vector or if it should be an attribute applied to an array. It was clang's various flavors of vectors with different semantics which ultimately led to the current proposal where it is an atribute. While the different flavors of vectors that clang supports are not sufficiently different to require an argument defining different flavors a flag attribute can easily be extended to accept a constant class if the need should ever arise. It should be noted that one of the more challenging types of vector for DWARF to deal with are variable vector lengths which are implementation specific on a per core basis rather than specified in the target architecture. It was thought that this may require a new flavor of vector type. However, in at least one case ARM's SVE, these challenges were addressed by moving the complexity out of DWARF and providing a pseudo register in the runtime environment that specifies the length of the vector. https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst#dwarf-register-names During the course of the discussion, it was pointed out that while no compiler currently supports matrix types, there are several current processors which have matrix registers that have intrinsics that allow a programmer to access them. One example is AMD's second generation CDNA processors and later. https://gpuopen.com/learn/amd-lab-notes/amd-lab-notes-matrix-cores-readme/ Rather than introducing a second new attribute like DW_AT_matrix, we thought that calling the attribute DW_AT_tensor was correct and general enough to embrace the concept. ------------------------------------------------- In Section 2.2 Attribute Types, DW_AT_tensor shall be added to Table 2.2 -------------------------------------------------------------------- ??? DW_AT_tensor??????????????? | A language tensor type -------------------------------------------------------------------- The hyperlink in the "Identifies or Specifies" column shall point to the paragraph added to Section 5.5 below for DW_AT_tensor. In Section 5.5 Array Type Entries, replace first paragraph of non-normative text with: -------------------------------------------------------------------- ??? [non-normative] Many languages share the concept of an ?array,? ??? which is a table of components of identical type. Furthermore, ??? many architectures contain vector types which mirror the language ??? concept of a short single dimension array but have different ??? encoding, a different calling convention and different arithmatic ??? and logical operational semantics than the source language ??? arrays. Likewise a few architectures are starting to add matrix ??? register types with similar variations in encoding and semantics ??? from normal source language array types. -------------------------------------------------------------------- Insert the following paragraph between the first paragraph of normative text describing DW_TAG_array_type and the second paragraph dealing with multidimensional ordering. -------------------------------------------------------------------- ??? An array type that refers to a vector or matrix type, shall be ??? denoted with DW_AT_tensor. The width and when applicable the ??? number of rows of the type shall be specified as array ??? dimensions. The type contained within the tensor array type must ??? be a DW_TAG_base_type entry. -------------------------------------------------------------------- An entry shall be added to the table of attributes in 7.5.4 defining this new attribute. giving this attribute a value. Something like: -------------------------------------------------------------------- ??? Table 7.5 ??? ----------------------------------- ??? Attribute Name??? | Value | Classes ??? ----------------------------------- ??? DW_AT_tensor????? | 0xNN? | flag ??? ----------------------------------- -------------------------------------------------------------------- From ccoutant@gmail.com Thu Jun 8 22:47:18 2023 From: ccoutant@gmail.com (Cary Coutant) Date: Thu, 8 Jun 2023 15:47:18 -0700 Subject: [Dwarf-discuss] Request for adding a Mojo Language Attribute In-Reply-To: References: Message-ID: > https://dwarfstd.org/issues/230502.1.html I've marked this issue as accepted, and have assigned DW_LANG_Mojo = 0x0033, with a default lower bound of 0. For DWARF 6, I've also assigned DW_LNAME_Mojo = 0x001f. -cary From walter@modular.com Fri Jun 9 00:54:40 2023 From: walter@modular.com (Walter Erquinigo) Date: Thu, 8 Jun 2023 19:54:40 -0500 Subject: [Dwarf-discuss] Request for adding a Mojo Language Attribute In-Reply-To: References: Message-ID: Much appreciated! On Thu, Jun 8, 2023 at 5:47?PM Cary Coutant wrote: > > https://dwarfstd.org/issues/230502.1.html > > I've marked this issue as accepted, and have assigned DW_LANG_Mojo = > 0x0033, with a default lower bound of 0. For DWARF 6, I've also > assigned DW_LNAME_Mojo = 0x001f. > > -cary > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woodard@redhat.com Fri Jun 16 15:28:45 2023 From: woodard@redhat.com (Ben Woodard) Date: Fri, 16 Jun 2023 08:28:45 -0700 Subject: [Dwarf-discuss] performance tools and inverted location lists Message-ID: I was looking at 2 level location tables https://dwarfstd.org/issues/140906.1.html and can see how it could improve things there. One thing that I noticed about it was that it was based on some prior art done in HP-UX. A nut that I have been trying to crack for a few years but haven't really figured out comes from the performance tools, binary analysis people and I could even make use of it for my ABI work. They would really like something that I've been calling "inverted location lists". Location lists are basically a function (yes I know it is technically a relation but let's not quibble about that right now): f( PC, "variable") -> location description This totally makes sense in the context of a debugger where the context of the lookup includes the PC, and the user inputs the symbolic name of the variable. The point that I try to make is DWARF is not just for debuggers anymore. A much broader range of consumers is emerging. In the context of performance tools, they need: f( PC, location) -> symbolic name The reason why I specify "concrete" location is because it is never going to be a literal constant or an implicit or a DWARF expression or any of the other things along those lines. It is going to be an address or a register, things that have concrete existence. Here are the use cases for this that have come up: * For performance tools, they have some piece of code which is not performing as it should. The tools show them that they are getting a large number of cache misses between this PC and another PC. They can disassemble the machine code and they see a handful of instructions. To be able to figure out what is wrong they need to associate the operands of these instructions to what they refer to at the source level. Doing this disassembled optimized machine code and then associating the data accesses within it back to constructs within the source language really puts this level of analysis is the domain of experts and must be done by hand. Because of the limited information currently provided by DWARF it is not something that can be coded into a tool. * Within ABI analysis there are a few cases where compilation options can change the calling convention of a function sufficiently enough that it can create an ABI mismatch. The simple example that illustrates the point is SSE. You can pass vector operands by value in vector registers. However, if you compile a program without SSE then it is passed by reference. So in the ABI testing program, if I take the locations of the formal parameters at the call site and then use an inverted location list to look up what variables exist at those locations in the called function, if they don't match then I have an ABI problem. * One binary analysis use case is quite similar to the ABI use case, they see a call instruction, they can look up the target of the call to find the function prototype. From that they can figure out where the parameters to the function call are at the time of the call. However, they want to know in the calling scope what symbolic name in the source language for the parameter in a particular location at the time of the call. Simple example: find all the examples of "dlopen" calls - what library name is being opened, is it something that we can determine from static analysis or is it something read from a config file... What all three of us have tried doing with limited success is taking the location list data and then inverting the mappings. The problem is that this is far from complete and generating that data is very computationally expensive. I've looked for prior art to see if someone had come up with a solution to this but I haven't found any. The allusion to the HP-UX two level line maps is something that I had never come across before. Since the combined experience of this group is much deeper than what I have, does anybody know of any prior art that I can use as a basis for a DWARF feature enhancement issue? -ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From khuey@pernos.co Fri Jun 16 15:51:02 2023 From: khuey@pernos.co (Kyle Huey) Date: Fri, 16 Jun 2023 08:51:02 -0700 Subject: [Dwarf-discuss] performance tools and inverted location lists In-Reply-To: References: Message-ID: On Fri, Jun 16, 2023 at 8:28?AM Ben Woodard via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > I was looking at 2 level location tables > https://dwarfstd.org/issues/140906.1.html and can see how it could > improve things there. One thing that I noticed about it was that it was > based on some prior art done in HP-UX. > > A nut that I have been trying to crack for a few years but haven't really > figured out comes from the performance tools, binary analysis people and I > could even make use of it for my ABI work. They would really like something > that I've been calling "inverted location lists". Location lists are > basically a function (yes I know it is technically a relation but let's not > quibble about that right now): > > f( PC, "variable") -> location description > > This totally makes sense in the context of a debugger where the context of > the lookup includes the PC, and the user inputs the symbolic name of the > variable. The point that I try to make is DWARF is not just for debuggers > anymore. A much broader range of consumers is emerging. > > In the context of performance tools, they need: > > f( PC, location) -> symbolic name > > The reason why I specify "concrete" location is because it is never going > to be a literal constant or an implicit or a DWARF expression or any of the > other things along those lines. It is going to be an address or a register, > things that have concrete existence. > lldb has a version of this function implemented in the functions StackFrame::GuessValueForAddress/GuessValueForRegisterAndOffset. - Kyle > Here are the use cases for this that have come up: > > - For performance tools, they have some piece of code which is not > performing as it should. The tools show them that they are getting a large > number of cache misses between this PC and another PC. They can disassemble > the machine code and they see a handful of instructions. To be able to > figure out what is wrong they need to associate the operands of these > instructions to what they refer to at the source level. Doing this > disassembled optimized machine code and then associating the data accesses > within it back to constructs within the source language really puts this > level of analysis is the domain of experts and must be done by hand. > Because of the limited information currently provided by DWARF it is not > something that can be coded into a tool. > - Within ABI analysis there are a few cases where compilation options > can change the calling convention of a function sufficiently enough that it > can create an ABI mismatch. The simple example that illustrates the point > is SSE. You can pass vector operands by value in vector registers. However, > if you compile a program without SSE then it is passed by reference. So in > the ABI testing program, if I take the locations of the formal parameters > at the call site and then use an inverted location list to look up what > variables exist at those locations in the called function, if they don't > match then I have an ABI problem. > - One binary analysis use case is quite similar to the ABI use case, > they see a call instruction, they can look up the target of the call to > find the function prototype. From that they can figure out where the > parameters to the function call are at the time of the call. However, they > want to know in the calling scope what symbolic name in the source language > for the parameter in a particular location at the time of the call. Simple > example: find all the examples of "dlopen" calls - what library name is > being opened, is it something that we can determine from static analysis or > is it something read from a config file... > > What all three of us have tried doing with limited success is taking the > location list data and then inverting the mappings. The problem is that > this is far from complete and generating that data is very computationally > expensive. > > I've looked for prior art to see if someone had come up with a solution to > this but I haven't found any. The allusion to the HP-UX two level line maps > is something that I had never come across before. Since the combined > experience of this group is much deeper than what I have, does anybody know > of any prior art that I can use as a basis for a DWARF feature enhancement > issue? > > -ben > > > -- > 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 caraleigh.chalmers@gmail.com Fri Jun 16 19:24:51 2023 From: caraleigh.chalmers@gmail.com (Cara-Leigh Chalmers) Date: Fri, 16 Jun 2023 21:24:51 +0200 Subject: [Dwarf-discuss] (no subject) Message-ID: <3E137C10-41AB-44C9-BD5B-0BAE32084708@hxcore.ol> An HTML attachment was scrubbed... URL: From duvern35@outlook.com Fri Jun 16 23:19:45 2023 From: duvern35@outlook.com (Louise duvern) Date: Fri, 16 Jun 2023 23:19:45 +0000 Subject: [Dwarf-discuss] (no subject) Message-ID: Sent from Mail for Windows -------------- next part -------------- An HTML attachment was scrubbed... URL: From woodard@redhat.com Mon Jun 19 20:32:05 2023 From: woodard@redhat.com (Ben Woodard) Date: Mon, 19 Jun 2023 13:32:05 -0700 Subject: [Dwarf-discuss] Link to current working DWARF6 standard Message-ID: Can we please add a link to the current evolving DWARF6 standard working draft somewhere on https://dwarfstd.org/index.html I was wanting to show someone that we have the current working copy that we produce and I was sure that you could navigate to it from the main page but I was unable to find it that way. If it is there (and I couldn?t find it) could we make it obvious? -ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark@klomp.org Mon Jun 19 21:11:36 2023 From: mark@klomp.org (Mark Wielaard) Date: Mon, 19 Jun 2023 23:11:36 +0200 Subject: [Dwarf-discuss] Link to current working DWARF6 standard In-Reply-To: References: Message-ID: <20230619211136.GJ24233@gnu.wildebeest.org> Hi Ben, On Mon, Jun 19, 2023 at 01:32:05PM -0700, Ben Woodard via Dwarf-discuss wrote: > Can we please add a link to the current evolving DWARF6 standard > working draft somewhere on https://dwarfstd.org/index.html > > I was wanting to show someone that we have the current working copy > that we produce and I was sure that you could navigate to it from > the main page but I was unable to find it that way. If it is there > (and I couldn?t find it) could we make it obvious? I don't know what the best place is to put a link, but the current draft can be found in git: https://git.dwarfstd.org/dwarf-spec There is a Makefile inside the latexdoc directory that will build you a PDF version. You can also find an automaticly generated snapshot at: https://snapshots.sourceware.org/dwarfstd/dwarf-spec/latest/ Please note that these are of course WORKING DRAFTS (it says so on every page). There is a Change Summary that tells which Issues have been incorporated. But new issues can still change things. Also the changebars are currently missing. If someone with some latex knowledge knows how to get them to show up in the PDF version that would be appreciated. Cheers, Mark From ccoutant@gmail.com Tue Jun 20 23:02:08 2023 From: ccoutant@gmail.com (Cary Coutant) Date: Tue, 20 Jun 2023 16:02:08 -0700 Subject: [Dwarf-discuss] Link to current working DWARF6 standard In-Reply-To: <20230619211136.GJ24233@gnu.wildebeest.org> References: <20230619211136.GJ24233@gnu.wildebeest.org> Message-ID: We agreed in the April 17 meeting to make the working copies of the DWARF spec public. I've added a DWARF 6 section to the home page, with a link to the working draft snapshots, and I've added DWARF 6 to the downloads page. -cary On Mon, Jun 19, 2023 at 2:11?PM Mark Wielaard via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Hi Ben, > > On Mon, Jun 19, 2023 at 01:32:05PM -0700, Ben Woodard via Dwarf-discuss > wrote: > > Can we please add a link to the current evolving DWARF6 standard > > working draft somewhere on https://dwarfstd.org/index.html > > > > I was wanting to show someone that we have the current working copy > > that we produce and I was sure that you could navigate to it from > > the main page but I was unable to find it that way. If it is there > > (and I couldn?t find it) could we make it obvious? > > I don't know what the best place is to put a link, but the current > draft can be found in git: https://git.dwarfstd.org/dwarf-spec > > There is a Makefile inside the latexdoc directory that will build you > a PDF version. > > You can also find an automaticly generated snapshot at: > https://snapshots.sourceware.org/dwarfstd/dwarf-spec/latest/ > > Please note that these are of course WORKING DRAFTS (it says so on > every page). There is a Change Summary that tells which Issues have > been incorporated. But new issues can still change things. > > Also the changebars are currently missing. If someone with some latex > knowledge knows how to get them to show up in the PDF version that > would be appreciated. > > Cheers, > > Mark > -- > 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 mark@klomp.org Wed Jun 21 20:24:08 2023 From: mark@klomp.org (Mark Wielaard) Date: Wed, 21 Jun 2023 22:24:08 +0200 Subject: [Dwarf-discuss] Link to current working DWARF6 standard In-Reply-To: References: <20230619211136.GJ24233@gnu.wildebeest.org> Message-ID: <20230621202408.GQ24233@gnu.wildebeest.org> Hi, On Tue, Jun 20, 2023 at 04:02:08PM -0700, Cary Coutant wrote: > We agreed in the April 17 meeting to make the working copies of the DWARF > spec public. > > I've added a DWARF 6 section to the home page, with a link to the working > draft snapshots, and I've added DWARF 6 to the downloads page. Thanks. I tweaked the git links since the DWARF5 git and current work in progress spec git are separate repos/links (dwarf-doc vs dwarf-spec). Cheers, Mark