From eager@eagercon.com Tue Apr 2 14:00:24 2024 From: eager@eagercon.com (Michael Eager) Date: Tue, 2 Apr 2024 07:00:24 -0700 Subject: [Dwarf-discuss] DWARF problem with Debugging Information In-Reply-To: References: Message-ID: <7f75ea67-e56a-437e-aa22-961f13655884@eagercon.com> Hi Akin -- I've CC'ed the DWARF discussion group. There may be others who have thoughts about your question. Most questions about the use of DWARF should be directed to the mailing list. You may need to join the mailing list to submit questions or reply. A decompiler is an ambitious project. The compilation process is one where considerable information about the source is discarded as code is generated. DWARF will only be able to replace some of that info. Regarding your question about literal values: The line table associates object code addresses with source line numbers. The line table does not describe data, whether variables or literal. Variables are described by DW_TAG_variable entries. They have a DW_AT_location attribute which (when decoded) describes where the variable is stored. For the most part, literal values are not described in DWARF. Literal values may be stored in memory or they may be dynamically generated in the object code. In either case, DWARF does not contain information describing literals. In your example, line 6 is the printf of globalVar which starts at address 0x1160. That is clear from the line table. (Executing objdump with -S will make this more obvious.) The line table only describes where the object code for a source line can be found. It does not describe any references to variables, literals, functions, or anything else. So, no, there is no entry for address 0x1168 where address 2009 (which I presume is the format string) is referenced. I hope this helps. On 3/31/24 08:15, Burhan Akin Y wrote: > Dear Mr. Eager, > > I am a student from the Heidelberg University in Germany and I am > interested in using DWARF Debugging Information for our decompiler > development project. > > The idea is to train a Seq2Seq model on translating between Disassembly > and C Code (our focus is non-optimized programs). > https://github.com/nokitoino/DecompilerAI > > > We are trying to solve a little problem. Our training is done > function-wise so far. > > The problem is that some literal values are not stored locally at the > current dumped disassembly of the function, but rather at some memory > offset. > > The idea is to prepare the training data like this: > > E.g.: > int globalVar = 10; -> int globalVar = /*int_4010*/; > char* test = "Test"; -> char* test = /*str_2004*/; > ... > Where 2004 is the address of where the string is stored at in the > .rodata section, and 4010 the integer value in the .data section. > > That means, the model should learn to put the memory addresses when it > is predicting C code from disassembly (since trained function-wise, it > has no access to any other information like the .rodata, but only to the > addresses.). And later we can manually post-process it to extract the > string from the memory. > > We have thought about using DWARF decodedline, which tells us which line > in our C source code associates with which address on the disassembly. > > If you take a look at the image I have attached on this e-mail, you will > notice that not all literal occurences are associated with a memory > address. The printf("%d",globalVar) should have an association to line > 1168, where the address 2009 is. > > Could I have some explanation for this behaviour and advices on how we > could solve this problem? > > We would acknowledge any help. > > Best regards > > Akin Yilmaz > > -- Michael Eager -------------- next part -------------- A non-text attachment was scrubbed... Name: DWARF Demonstration.png Type: image/png Size: 109914 bytes Desc: not available URL: From sevaa@sprynet.com Sun Apr 7 17:20:49 2024 From: sevaa@sprynet.com (Vsevolod Alekseyev) Date: Sun, 7 Apr 2024 13:20:49 -0400 Subject: [Dwarf-discuss] Expression opcode 0xD0 Message-ID: <000701da890f$efdcf140$cf96d3c0$@sprynet.com> Hi all, I've got a crash report that my DWARF expression parser crashed on the following expression blob: 09 03 D0 39 8C That looks like DW_OP_const1s with 3 as the argument, followed by a bogus opcode D0. It's not a valid opcode and not in the user extension area. Anyone ever encountered this? I don't have a ton of context for the crash. I know the binary was an AArch64 ELF, but that's about it. Don't know whether it was in a loclist or in an attribute. There is a minor possibility that something that was not meant to be an expression was being interpreted as one, but that's quite unlikely; there aren't too many attributes with byte array typed values. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davea42@gmail.com Tue Apr 9 17:10:15 2024 From: davea42@gmail.com (David Anderson) Date: Tue, 9 Apr 2024 10:10:15 -0700 Subject: [Dwarf-discuss] Expression opcode 0xD0 In-Reply-To: <000701da890f$efdcf140$cf96d3c0$@sprynet.com> References: <000701da890f$efdcf140$cf96d3c0$@sprynet.com> Message-ID: <76f6f33e-706a-4752-ba41-e6cdb3ace687@gmail.com> On 4/7/24 10:20, Vsevolod Alekseyev via Dwarf-discuss wrote: > I?ve got a crash report that my DWARF expression parser crashed on the > following expression blob: > > 09 03 D0 39 8C > > That looks like DW_OP_const1s with 3 as the argument, followed by a > bogus opcode D0. It?s not a valid opcode and not in the user extension > area. Anyone ever encountered this? > I have no record of any DW_OP_ with code 0xD? for any value of ? David Anderson, libdwarf From gimcm99@gmail.com Thu Apr 18 07:58:16 2024 From: gimcm99@gmail.com (G McM) Date: Thu, 18 Apr 2024 03:58:16 -0400 Subject: [Dwarf-discuss] (no subject) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From aprantl@apple.com Tue Apr 23 00:00:13 2024 From: aprantl@apple.com (Adrian Prantl) Date: Mon, 22 Apr 2024 17:00:13 -0700 Subject: [Dwarf-discuss] Proposal: Define a language version scheme for Swift Message-ID: # Swift Language version scheme ## Background The list of languages at https://dwarfstd.org/languages-v6.html does not list a version scheme for the Swift language. This proposal adds one. ## Overview The Swift programming language does not have a version scheme defined for DW_AT_language_version. This proposal defines it to use the `VVMM` version scheme. This way "Swift 5.10" would be ``` DW_AT_language(DW_LANG_Swift) DW_AT_language_version(510) ``` and "Swift 6" would be `DW_AT_language_version(600)`. Even though Swift package releases usually have a Major.Minor.Patch version scheme (e.g., Swift 5.9.2), the Swift compiler frontend's LangOptions data structure only uses Major.Minor to distinguish syntax changes in the parser (see References). This version scheme is designed to match what the compiler does. ## Proposed Changes Augment the table of language encodings to say ``` Swift DW_LNAME_Swift 0x001a 0 VVMM ``` ## Dependencies Issue 210419.1 ## References https://www.swift.org/download/ (see older releases for a history of versions). https://github.com/apple/swift/blob/3d32f5fc8a9087add424a2704ef1dcd89c9307ff/include/swift/Basic/LangOptions.h#L174 From aprantl@apple.com Wed Apr 24 00:06:21 2024 From: aprantl@apple.com (Adrian Prantl) Date: Tue, 23 Apr 2024 17:06:21 -0700 Subject: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d Message-ID: <021CF746-93B7-40F1-BABA-4E91F73C968A@apple.com> # Error: Duplicate DW_AT_LNAME 1d ## Overview The list of DWARF Version 6 Language and Version Codes double-assigns the DW_AT_LNAME code 0x001d to "HIP" and "Assembly". ## Proposed Changes Reassign HIP to 0x0029. ## References https://dwarfstd.org/languages-v6.html From ron.brender@gmail.com Wed Apr 24 12:46:15 2024 From: ron.brender@gmail.com (Ron Brender) Date: Wed, 24 Apr 2024 08:46:15 -0400 Subject: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d In-Reply-To: <021CF746-93B7-40F1-BABA-4E91F73C968A@apple.com> References: <021CF746-93B7-40F1-BABA-4E91F73C968A@apple.com> Message-ID: It appears that DW_LNAME_HIP, proposed in 230120.4, never got incorporated into the DWARF working document (so there is no duplication). Perhaps because the Issue status is "Code Assigned" rather than Approved. That status really only applies to the V5 code assignment actually. Anyway, I'll fix it for V6. The next available code is 0x0027. What makes you think the code should be 0x0029? Ron On Tue, Apr 23, 2024 at 8:06?PM Adrian Prantl via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > # Error: Duplicate DW_AT_LNAME 1d > > ## Overview > > The list of DWARF Version 6 Language and Version Codes double-assigns the > DW_AT_LNAME code 0x001d to "HIP" and "Assembly". > > ## Proposed Changes > > Reassign HIP to 0x0029. > > ## References > > https://dwarfstd.org/languages-v6.html > > -- > Dwarf-discuss mailing list > Dwarf-discuss@lists.dwarfstd.org > https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aprantl@apple.com Wed Apr 24 16:06:42 2024 From: aprantl@apple.com (Adrian Prantl) Date: Wed, 24 Apr 2024 09:06:42 -0700 Subject: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d In-Reply-To: References: <021CF746-93B7-40F1-BABA-4E91F73C968A@apple.com> Message-ID: <00697DF5-CE38-4621-BDFD-C7309F49A80D@apple.com> > On Apr 24, 2024, at 5:46?AM, Ron Brender wrote: > > It appears that DW_LNAME_HIP, proposed in 230120.4, never got incorporated into the DWARF working document (so there is no duplication). Perhaps because the Issue status is "Code Assigned" rather than Approved. That status really only applies to the V5 code assignment actually. > > Anyway, I'll fix it for V6. > > The next available code is 0x0027. What makes you think the code should be 0x0029? I was looking at https://dwarfstd.org/languages-v6.html where the last assigned langiage is DW_LNAME_Hylo 0x0028. -- adrian > > Ron > > > On Tue, Apr 23, 2024 at 8:06?PM Adrian Prantl via Dwarf-discuss > wrote: >> # Error: Duplicate DW_AT_LNAME 1d >> >> ## Overview >> >> The list of DWARF Version 6 Language and Version Codes double-assigns the DW_AT_LNAME code 0x001d to "HIP" and "Assembly". >> >> ## Proposed Changes >> >> Reassign HIP to 0x0029. >> >> ## References >> >> https://dwarfstd.org/languages-v6.html >> >> -- >> Dwarf-discuss mailing 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 Wed Apr 24 16:25:35 2024 From: ccoutant@gmail.com (Cary Coutant) Date: Wed, 24 Apr 2024 09:25:35 -0700 Subject: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d In-Reply-To: <00697DF5-CE38-4621-BDFD-C7309F49A80D@apple.com> References: <021CF746-93B7-40F1-BABA-4E91F73C968A@apple.com> <00697DF5-CE38-4621-BDFD-C7309F49A80D@apple.com> Message-ID: > > It appears that DW_LNAME_HIP, proposed in 230120.4, never got > incorporated into the DWARF working document (so there is no duplication). > Perhaps because the Issue status is "Code Assigned" rather than Approved. > That status really only applies to the V5 code assignment actually. > > Anyway, I'll fix it for V6. > > The next available code is 0x0027. What makes you think the code should be > 0x0029? > > > I was looking at https://dwarfstd.org/languages-v6.html where the last > assigned langiage is DW_LNAME_Hylo 0x0028. > DW_LANG_HIP/DW_LNAME_HIP was assigned first, but for some reason, the list was out of order, so when I assigned DW_LNAME_Assembly, it looked like 0x001c was the last code assigned. I think it would be safer to reassign DW_LNAME_Assembly as 0x0029. -cary -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccoutant@gmail.com Wed Apr 24 16:30:13 2024 From: ccoutant@gmail.com (Cary Coutant) Date: Wed, 24 Apr 2024 09:30:13 -0700 Subject: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d In-Reply-To: References: <021CF746-93B7-40F1-BABA-4E91F73C968A@apple.com> Message-ID: > > > It appears that DW_LNAME_HIP, proposed in 230120.4, never got > incorporated into the DWARF working document (so there is no duplication). > Perhaps because the Issue status is "Code Assigned" rather than Approved. > That status really only applies to the V5 code assignment actually. > I've been following Michael's protocol of using the status "Language Code Assigned" for new language codes, where no committee discussion is necessary. Would it help your process if I added the word "Accepted" to the issue status? -cary -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.brender@gmail.com Wed Apr 24 16:56:38 2024 From: ron.brender@gmail.com (Ron Brender) Date: Wed, 24 Apr 2024 12:56:38 -0400 Subject: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d In-Reply-To: References: <021CF746-93B7-40F1-BABA-4E91F73C968A@apple.com> Message-ID: Cary, Actually, it would help my process if you would announce at each meeting what language names and their corresponding issue numbers were processed in the prior period. The point is to get that information into the Minutes. No discussion needed, just an announcement. Actually if that information is presented in the Agenda for a meeting that would probably suffice, although it is the minutes that should be complete and definitive. Thanks, Ron On Wed, Apr 24, 2024 at 12:30?PM Cary Coutant wrote: > >> It appears that DW_LNAME_HIP, proposed in 230120.4, never got >> incorporated into the DWARF working document (so there is no duplication). >> Perhaps because the Issue status is "Code Assigned" rather than Approved. >> That status really only applies to the V5 code assignment actually. >> > > I've been following Michael's protocol of using the status "Language Code > Assigned" for new language codes, where no committee discussion is > necessary. Would it help your process if I added the word "Accepted" to the > issue status? > > -cary > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.brender@gmail.com Wed Apr 24 17:04:57 2024 From: ron.brender@gmail.com (Ron Brender) Date: Wed, 24 Apr 2024 13:04:57 -0400 Subject: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d In-Reply-To: References: <021CF746-93B7-40F1-BABA-4E91F73C968A@apple.com> <00697DF5-CE38-4621-BDFD-C7309F49A80D@apple.com> Message-ID: Cary, >DW_LANG_HIP/DW_LNAME_HIP was assigned first, but for some reason, the list was out of order, so when I assigned >DW_LNAME_Assembly, it looked like 0x001c was the last code assigned. I think it would be safer to reassign >DW_LNAME_Assembly as 0x0029. I think it would be safer to just leave well-enough alone. I just updated the document to match the website (and make DW_LNAME_HIP = 0x0029). So any change causes work for me. Similarly it creates work for anyone who is actually trying to use code DW_LNAME_Assembly. Why bother? Ron On Wed, Apr 24, 2024 at 12:25?PM Cary Coutant wrote: > It appears that DW_LNAME_HIP, proposed in 230120.4, never got >> incorporated into the DWARF working document (so there is no duplication). >> Perhaps because the Issue status is "Code Assigned" rather than Approved. >> That status really only applies to the V5 code assignment actually. >> >> Anyway, I'll fix it for V6. >> >> The next available code is 0x0027. What makes you think the code should >> be 0x0029? >> >> >> I was looking at https://dwarfstd.org/languages-v6.html where the last >> assigned langiage is DW_LNAME_Hylo 0x0028. >> > > DW_LANG_HIP/DW_LNAME_HIP was assigned first, but for some reason, the list > was out of order, so when I assigned DW_LNAME_Assembly, it looked like > 0x001c was the last code assigned. I think it would be safer to reassign > DW_LNAME_Assembly as 0x0029. > > -cary > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aprantl@apple.com Wed Apr 24 21:25:37 2024 From: aprantl@apple.com (Adrian Prantl) Date: Wed, 24 Apr 2024 14:25:37 -0700 Subject: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics Message-ID: <1DD124FA-F75B-4E42-9E33-964E67BAF055@apple.com> # C standard release dates for DW_AT_language_version, clarify semantics ## Background The list of languages at https://dwarfstd.org/languages-v6.html does not list release dates for the ISO C standard. Producers need to know what version numbers they should produce though. I scanned the ISO website for appropriate dates to use. ## Proposed Changes Augment the table of language encodings to add C (K&R and ISO) DW_LNAME_C 0x0003 0 YYYYMM K&R 000000 C89 198912 C99 199912 C11 201112 C17 201806 (sic!) C2x >201806 Add the following non-normative wording: To convert a version number to a specific release, it is good practice to treat the YYYMM version numbers listed in this document as the maximum version that is interpreted as belonging to a specific release. This way consumers can emit version numbers for unreleased upcoming specifications, by using, e.g., the date the compiler was built. ## Dependencies Issue 210419.1 ## References https://iso-9899.info/wiki/The_Standard C89: https://www.iso.org/standard/17782.html C99: https://www.iso.org/standard/29237.html C11: https://www.iso.org/standard/57853.html C17: https://www.iso.org/standard/74528.html https://dwarfstd.org/languages-v6.html From aprantl@apple.com Wed Apr 24 21:36:18 2024 From: aprantl@apple.com (Adrian Prantl) Date: Wed, 24 Apr 2024 14:36:18 -0700 Subject: [Dwarf-discuss] Proposal: Add versioning scheme for Fortran Message-ID: <48DE3561-FD95-4185-92B4-CAFFA63D7B9B@apple.com> # Add versioning scheme for Fortran ## Background The list of languages at https://dwarfstd.org/languages-v6.html does not list a versioning scheme for Fortran, but we have DWARF 5 language constants for FORTRAN77 through Fortran08. ## Proposed Changes Augment the table of language encodings to add `YYYY` to Fortran as a version scheme. ## Dependencies Issue 210419.1 ## References https://dwarfstd.org/languages-v6.html From aprantl@apple.com Wed Apr 24 21:45:25 2024 From: aprantl@apple.com (Adrian Prantl) Date: Wed, 24 Apr 2024 14:45:25 -0700 Subject: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics In-Reply-To: <1DD124FA-F75B-4E42-9E33-964E67BAF055@apple.com> References: <1DD124FA-F75B-4E42-9E33-964E67BAF055@apple.com> Message-ID: <84648BD1-324E-4FB2-B265-AFD4335E14B5@apple.com> The back story here is that I am trying to implement the new language attributes in LLVM, which is why I'm finding all these bugs, omissions, and ambiguities: https://github.com/llvm/llvm-project/pull/89980 cheers, Adrian > On Apr 24, 2024, at 2:25?PM, Adrian Prantl via Dwarf-discuss wrote: > > # C standard release dates for DW_AT_language_version, clarify semantics > > ## Background > > The list of languages at https://dwarfstd.org/languages-v6.html does not list release dates for the ISO C standard. Producers need to know what version numbers they should produce though. I scanned the ISO website for appropriate dates to use. > > ## Proposed Changes > > Augment the table of language encodings to add > C (K&R and ISO) DW_LNAME_C 0x0003 0 YYYYMM > > K&R 000000 > C89 198912 > C99 199912 > C11 201112 > C17 201806 (sic!) > C2x >201806 > > Add the following non-normative wording: > > To convert a version number to a specific release, it is good practice to treat the YYYMM version numbers listed in this document as the maximum version that is interpreted as belonging to a specific release. This way consumers can emit version numbers for unreleased upcoming specifications, by using, e.g., the date the compiler was built. > > ## Dependencies > > Issue 210419.1 > > ## References > > https://iso-9899.info/wiki/The_Standard > > C89: https://www.iso.org/standard/17782.html > C99: https://www.iso.org/standard/29237.html > C11: https://www.iso.org/standard/57853.html > C17: https://www.iso.org/standard/74528.html > > https://dwarfstd.org/languages-v6.html > -- > Dwarf-discuss mailing list > Dwarf-discuss@lists.dwarfstd.org > https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss From jakub@redhat.com Wed Apr 24 21:49:34 2024 From: jakub@redhat.com (Jakub Jelinek) Date: Wed, 24 Apr 2024 23:49:34 +0200 Subject: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics In-Reply-To: <1DD124FA-F75B-4E42-9E33-964E67BAF055@apple.com> References: <1DD124FA-F75B-4E42-9E33-964E67BAF055@apple.com> Message-ID: On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss wrote: > # C standard release dates for DW_AT_language_version, clarify semantics > > ## Background > > The list of languages at https://dwarfstd.org/languages-v6.html does not list release dates for the ISO C standard. Producers need to know what version numbers they should produce though. I scanned the ISO website for appropriate dates to use. > > ## Proposed Changes > > Augment the table of language encodings to add > C (K&R and ISO) DW_LNAME_C 0x0003 0 YYYYMM > > K&R 000000 > C89 198912 > C99 199912 > C11 201112 > C17 201806 (sic!) > C2x >201806 That is not correct. C99 199901 C11 201112 C17 201710 C23 202311 C89 with ammendment 1 would be 199409 C89 likely that 198912 indeed. As for C++, the above page is missing C++23 202302 > > Add the following non-normative wording: > > To convert a version number to a specific release, it is good practice to treat the YYYMM version numbers listed in this document as the maximum version that is interpreted as belonging to a specific release. > This way consumers can emit version numbers for unreleased upcoming specifications, by using, e.g., the date the compiler was built. That is not a good suggestion. If a compiler supports some part of e.g. C23 but not everything, it should be something larger than 201710 but smaller than 202311, even when the date the compiler was built could be 202404 or later. GCC and Clang up to 17 used e.g. 202000 for C23 partial implementations, GCC still does, Clang 18+ now uses 202311. Jakub From aprantl@apple.com Wed Apr 24 21:57:17 2024 From: aprantl@apple.com (Adrian Prantl) Date: Wed, 24 Apr 2024 14:57:17 -0700 Subject: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics In-Reply-To: References: <1DD124FA-F75B-4E42-9E33-964E67BAF055@apple.com> Message-ID: <969F38B8-A4D6-4ADA-8D0C-7B82BE18F8C1@apple.com> > On Apr 24, 2024, at 2:49?PM, Jakub Jelinek wrote: > > On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss wrote: >> # C standard release dates for DW_AT_language_version, clarify semantics >> >> ## Background >> >> The list of languages at https://dwarfstd.org/languages-v6.html does not list release dates for the ISO C standard. Producers need to know what version numbers they should produce though. I scanned the ISO website for appropriate dates to use. >> >> ## Proposed Changes >> >> Augment the table of language encodings to add >> C (K&R and ISO) DW_LNAME_C 0x0003 0 YYYYMM >> >> K&R 000000 >> C89 198912 >> C99 199912 >> C11 201112 >> C17 201806 (sic!) >> C2x >201806 > > That is not correct. > C99 199901 > C11 201112 > C17 201710 > C23 202311 Thanks for correcting these! Do you happen to have a link to the source you used to look these up? > > C89 with ammendment 1 would be > 199409 > C89 likely that 198912 indeed. > > As for C++, the above page is missing > C++23 202302 >> >> Add the following non-normative wording: >> >> To convert a version number to a specific release, it is good practice to treat the YYYMM version numbers listed in this document as the maximum version that is interpreted as belonging to a specific release. > >> This way consumers can emit version numbers for unreleased upcoming specifications, by using, e.g., the date the compiler was built. > > That is not a good suggestion. > If a compiler supports some part of e.g. C23 but not everything, it should > be something larger than 201710 but smaller than 202311, even when the date > the compiler was built could be 202404 or later. > GCC and Clang up to 17 used e.g. 202000 for C23 partial implementations, > GCC still does, Clang 18+ now uses 202311. That is what I had in mind, but I didn't think about a compiler built after a standard was released. Do you have a suggestion for a better wording to capture that nuance? thanks, Adrian > > Jakub From jakub@redhat.com Wed Apr 24 22:08:05 2024 From: jakub@redhat.com (Jakub Jelinek) Date: Thu, 25 Apr 2024 00:08:05 +0200 Subject: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics In-Reply-To: <969F38B8-A4D6-4ADA-8D0C-7B82BE18F8C1@apple.com> References: <1DD124FA-F75B-4E42-9E33-964E67BAF055@apple.com> <969F38B8-A4D6-4ADA-8D0C-7B82BE18F8C1@apple.com> Message-ID: On Wed, Apr 24, 2024 at 02:57:17PM -0700, Adrian Prantl wrote: > > > > On Apr 24, 2024, at 2:49?PM, Jakub Jelinek wrote: > > > > On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss wrote: > >> # C standard release dates for DW_AT_language_version, clarify semantics > >> > >> ## Background > >> > >> The list of languages at https://dwarfstd.org/languages-v6.html does not list release dates for the ISO C standard. Producers need to know what version numbers they should produce though. I scanned the ISO website for appropriate dates to use. > >> > >> ## Proposed Changes > >> > >> Augment the table of language encodings to add > >> C (K&R and ISO) DW_LNAME_C 0x0003 0 YYYYMM > >> > >> K&R 000000 > >> C89 198912 > >> C99 199912 > >> C11 201112 > >> C17 201806 (sic!) > >> C2x >201806 > > > > That is not correct. > > C99 199901 > > C11 201112 > > C17 201710 > > C23 202311 > > Thanks for correcting these! Do you happen to have a link to the source you used to look these up? E.g. the C23 standard? M.2 Fifth Edition Major changes in this fifth edition (__STDC_VERSION__ 202311L) include: ... M.3 Fourth Edition There were no major changes in the fourth edition (__STDC_VERSION__ 201710L), only technical corrections and clarifications. M.4 Third Edition Major changes in the third edition (__STDC_VERSION__ 201112L) included: ... M.5 Second Edition Major changes in the second edition (__STDC_VERSION__ 199901L) included: ... M.6 First Edition, Amendment 1 Major changes in the amendment to the first edition (__STDC_VERSION__ 199409L) included: The intent is for C versions which do have __STDC_VERSION__ to match that macro, similarly for C++ versions which do have __cplusplus macro of the YYYYMM form to match that macro. The dates in there are when the standard has been voted in (usually it takes then a few months to get officially released as ISO standard). > >> This way consumers can emit version numbers for unreleased upcoming specifications, by using, e.g., the date the compiler was built. > > > > That is not a good suggestion. > > If a compiler supports some part of e.g. C23 but not everything, it should > > be something larger than 201710 but smaller than 202311, even when the date > > the compiler was built could be 202404 or later. > > GCC and Clang up to 17 used e.g. 202000 for C23 partial implementations, > > GCC still does, Clang 18+ now uses 202311. > > That is what I had in mind, but I didn't think about a compiler built after a standard was released. Do you have a suggestion for a better wording to capture that nuance? Compilers should simply choose some number which will be known to be later than the latest released standards and expected to be smaller than the upcoming standard. E.g. using YYYY of the last standard + 1 and MM of 00 is a good practice, but DWARF shouldn't enforce that. Consumers aware of just C17 release should simply check for 201710 if testing about exactly C17, or > 201710 if testing for something later than that. Jakub From aprantl@apple.com Thu Apr 25 16:20:32 2024 From: aprantl@apple.com (Adrian Prantl) Date: Thu, 25 Apr 2024 09:20:32 -0700 Subject: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics In-Reply-To: References: <1DD124FA-F75B-4E42-9E33-964E67BAF055@apple.com> <969F38B8-A4D6-4ADA-8D0C-7B82BE18F8C1@apple.com> Message-ID: <2FAD5B29-8751-4AAE-BB16-F7454427F316@apple.com> Revised proposal based on feedback from Jakub! # C standard release dates for DW_AT_language_version, clarify semantics ## Background The list of languages at https://dwarfstd.org/languages-v6.html does not list release dates for the ISO C standard. Producers need to know what version numbers they should produce though. I scanned the ISO website for appropriate dates to use. ## Proposed Changes Augment the table of language encodings to add C (K&R and ISO) DW_LNAME_C 0x0003 0 YYYYMM K&R 000000 C89 198912 C99 199901 C11 201112 C17 201710 C23 202311 Add the following non-normative wording: Producers that implemented language features of an upcoming unreleased revision of a language with a YYYY or YYYYMM versioning scheme should pick a date that is greater than the latest release, but not in the future. Consumers that want to convert a YYYY or YYYMM version number to a specific release, should treat all version numbers in the range (A, B] as belonging to release B. ## Dependencies Issue 210419.1 ## References https://iso-9899.info/wiki/The_Standard https://dwarfstd.org/languages-v6.html > On Apr 24, 2024, at 3:08?PM, Jakub Jelinek via Dwarf-discuss wrote: > > On Wed, Apr 24, 2024 at 02:57:17PM -0700, Adrian Prantl wrote: >> >> >>> On Apr 24, 2024, at 2:49?PM, Jakub Jelinek wrote: >>> >>> On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss wrote: >>>> # C standard release dates for DW_AT_language_version, clarify semantics >>>> >>>> ## Background >>>> >>>> The list of languages at https://dwarfstd.org/languages-v6.html does not list release dates for the ISO C standard. Producers need to know what version numbers they should produce though. I scanned the ISO website for appropriate dates to use. >>>> >>>> ## Proposed Changes >>>> >>>> Augment the table of language encodings to add >>>> C (K&R and ISO) DW_LNAME_C 0x0003 0 YYYYMM >>>> >>>> K&R 000000 >>>> C89 198912 >>>> C99 199912 >>>> C11 201112 >>>> C17 201806 (sic!) >>>> C2x >201806 >>> >>> That is not correct. >>> C99 199901 >>> C11 201112 >>> C17 201710 >>> C23 202311 >> >> Thanks for correcting these! Do you happen to have a link to the source you used to look these up? > > E.g. the C23 standard? > M.2 Fifth Edition > Major changes in this fifth edition (__STDC_VERSION__ 202311L) include: > ... > M.3 Fourth Edition > There were no major changes in the fourth edition (__STDC_VERSION__ 201710L), only technical > corrections and clarifications. > M.4 Third Edition > Major changes in the third edition (__STDC_VERSION__ 201112L) included: > ... > M.5 Second Edition > Major changes in the second edition (__STDC_VERSION__ 199901L) included: > ... > M.6 First Edition, Amendment 1 > Major changes in the amendment to the first edition (__STDC_VERSION__ 199409L) included: > > The intent is for C versions which do have __STDC_VERSION__ to match that > macro, similarly for C++ versions which do have __cplusplus macro of the > YYYYMM form to match that macro. The dates in there are when the standard > has been voted in (usually it takes then a few months to get officially > released as ISO standard). > >>>> This way consumers can emit version numbers for unreleased upcoming specifications, by using, e.g., the date the compiler was built. >>> >>> That is not a good suggestion. >>> If a compiler supports some part of e.g. C23 but not everything, it should >>> be something larger than 201710 but smaller than 202311, even when the date >>> the compiler was built could be 202404 or later. >>> GCC and Clang up to 17 used e.g. 202000 for C23 partial implementations, >>> GCC still does, Clang 18+ now uses 202311. >> >> That is what I had in mind, but I didn't think about a compiler built after a standard was released. Do you have a suggestion for a better wording to capture that nuance? > > Compilers should simply choose some number which will be known to be later > than the latest released standards and expected to be smaller than the > upcoming standard. E.g. using YYYY of the last standard + 1 and MM of 00 > is a good practice, but DWARF shouldn't enforce that. > Consumers aware of just C17 release should simply check for 201710 if > testing about exactly C17, or > 201710 if testing for something later than > that. > > Jakub > > -- > Dwarf-discuss mailing list > Dwarf-discuss@lists.dwarfstd.org > https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss From ccoutant@gmail.com Fri Apr 26 21:21:14 2024 From: ccoutant@gmail.com (Cary Coutant) Date: Fri, 26 Apr 2024 14:21:14 -0700 Subject: [Dwarf-discuss] Proposal: Define a language version scheme for Swift In-Reply-To: References: Message-ID: I've added this as Issue 240422.1 . -cary On Mon, Apr 22, 2024 at 5:01?PM Adrian Prantl via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > # Swift Language version scheme > > ## Background > > The list of languages at https://dwarfstd.org/languages-v6.html does not > list a version scheme for the Swift language. This proposal adds one. > > ## Overview > > The Swift programming language does not have a version scheme defined for > DW_AT_language_version. This proposal defines it to use the `VVMM` version > scheme. This way "Swift 5.10" would be > > ``` > DW_AT_language(DW_LANG_Swift) > DW_AT_language_version(510) > ``` > > and "Swift 6" would be `DW_AT_language_version(600)`. Even though Swift > package releases usually have a Major.Minor.Patch version scheme (e.g., > Swift 5.9.2), the Swift compiler frontend's LangOptions data structure only > uses Major.Minor to distinguish syntax changes in the parser (see > References). This version scheme is designed to match what the compiler > does. > > ## Proposed Changes > > Augment the table of language encodings to say > > ``` > Swift DW_LNAME_Swift 0x001a 0 VVMM > ``` > > ## Dependencies > > Issue 210419.1 > > ## References > > https://www.swift.org/download/ (see older releases for a history of > versions). > > https://github.com/apple/swift/blob/3d32f5fc8a9087add424a2704ef1dcd89c9307ff/include/swift/Basic/LangOptions.h#L174 > -- > 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 Fri Apr 26 21:26:54 2024 From: ccoutant@gmail.com (Cary Coutant) Date: Fri, 26 Apr 2024 14:26:54 -0700 Subject: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d In-Reply-To: References: <021CF746-93B7-40F1-BABA-4E91F73C968A@apple.com> <00697DF5-CE38-4621-BDFD-C7309F49A80D@apple.com> Message-ID: > > > >DW_LANG_HIP/DW_LNAME_HIP was assigned first, but for some reason, the > list was out of order, so when I assigned >DW_LNAME_Assembly, it looked > like 0x001c was the last code assigned. I think it would be safer to > reassign >DW_LNAME_Assembly as 0x0029. > > I think it would be safer to just leave well-enough alone. I just updated > the document to match the website (and make DW_LNAME_HIP = 0x0029). So any > change causes work for me. Similarly it creates work for anyone who is > actually trying to use code DW_LNAME_Assembly. Why bother? > Looks like DW_LNAME_HIP never made it into the document after it was approved. Given the timing, it would make a little more sense to renumber Assembly instead, but since that's already in the document, and HIP isn't, I'll renumber HIP. Since this affects the DWARF 6 language codes only, we shouldn't have to worry about affecting anyone. Heads up, though: if anyone has started using DW_LNAME_HIP, please be aware of this change! I've added this as Issue 240423.1 . -cary -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccoutant@gmail.com Fri Apr 26 21:27:35 2024 From: ccoutant@gmail.com (Cary Coutant) Date: Fri, 26 Apr 2024 14:27:35 -0700 Subject: [Dwarf-discuss] Proposal: Add versioning scheme for Fortran In-Reply-To: <48DE3561-FD95-4185-92B4-CAFFA63D7B9B@apple.com> References: <48DE3561-FD95-4185-92B4-CAFFA63D7B9B@apple.com> Message-ID: Added as Issue 240424.1 . -cary On Wed, Apr 24, 2024 at 2:37?PM Adrian Prantl via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > # Add versioning scheme for Fortran > > ## Background > > The list of languages at https://dwarfstd.org/languages-v6.html does not > list a versioning scheme for Fortran, but we have DWARF 5 language > constants for FORTRAN77 through Fortran08. > > ## Proposed Changes > > Augment the table of language encodings to add `YYYY` to Fortran as a > version scheme. > > ## Dependencies > > Issue 210419.1 > > ## References > > https://dwarfstd.org/languages-v6.html > > -- > 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 Fri Apr 26 21:29:23 2024 From: ccoutant@gmail.com (Cary Coutant) Date: Fri, 26 Apr 2024 14:29:23 -0700 Subject: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics In-Reply-To: References: <1DD124FA-F75B-4E42-9E33-964E67BAF055@apple.com> Message-ID: Added as Issue 240424.2 , with Jakub's corrections. -cary On Wed, Apr 24, 2024 at 2:50?PM Jakub Jelinek via Dwarf-discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss > wrote: > > # C standard release dates for DW_AT_language_version, clarify semantics > > > > ## Background > > > > The list of languages at https://dwarfstd.org/languages-v6.html does > not list release dates for the ISO C standard. Producers need to know what > version numbers they should produce though. I scanned the ISO website for > appropriate dates to use. > > > > ## Proposed Changes > > > > Augment the table of language encodings to add > > C (K&R and ISO) DW_LNAME_C 0x0003 0 YYYYMM > > > > K&R 000000 > > C89 198912 > > C99 199912 > > C11 201112 > > C17 201806 (sic!) > > C2x >201806 > > That is not correct. > C99 199901 > C11 201112 > C17 201710 > C23 202311 > > C89 with ammendment 1 would be > 199409 > C89 likely that 198912 indeed. > > As for C++, the above page is missing > C++23 202302 > > > > Add the following non-normative wording: > > > > To convert a version number to a specific release, it is good practice > to treat the YYYMM version numbers listed in this document as the maximum > version that is interpreted as belonging to a specific release. > > > This way consumers can emit version numbers for unreleased upcoming > specifications, by using, e.g., the date the compiler was built. > > That is not a good suggestion. > If a compiler supports some part of e.g. C23 but not everything, it should > be something larger than 201710 but smaller than 202311, even when the date > the compiler was built could be 202404 or later. > GCC and Clang up to 17 used e.g. 202000 for C23 partial implementations, > GCC still does, Clang 18+ now uses 202311. > > Jakub > > -- > 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 Fri Apr 26 21:46:13 2024 From: ccoutant@gmail.com (Cary Coutant) Date: Fri, 26 Apr 2024 14:46:13 -0700 Subject: [Dwarf-discuss] Proposal: Error: Duplicate DW_AT_LNAME 1d In-Reply-To: References: <021CF746-93B7-40F1-BABA-4E91F73C968A@apple.com> Message-ID: > > Actually, it would help my process if you would announce at each meeting > what language names and their corresponding issue numbers were processed in > the prior period. The point is to get that information into the Minutes. No > discussion needed, just an announcement. Actually if that information is > presented in the Agenda for a meeting that would probably suffice, although > it is the minutes that should be complete and definitive. > Good idea. I'll do that. -cary -------------- next part -------------- An HTML attachment was scrubbed... URL: