From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id mB9BKnF/fmczLgcAWB0awg (envelope-from ) for ; Wed, 08 Jan 2025 08:36:49 -0500 Received: by simark.ca (Postfix, from userid 112) id A9C601E0C0; Wed, 8 Jan 2025 08:36:49 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 9D6131E05C for ; Wed, 8 Jan 2025 08:36:48 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4E0763857000 for ; Wed, 8 Jan 2025 13:36:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4E0763857000 Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id ADFAA3857B8C for ; Wed, 8 Jan 2025 13:35:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ADFAA3857B8C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ADFAA3857B8C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736343358; cv=none; b=oqxXz1STOeXyYAJMAHPiwQ/N76Ai97sSL81uFHFGeJH9/Lspxarf3gyeI1Bpg3/uovvEY7hf18h263SlMzLrtawNSe2cNnKAjgkoAipoOM9EIp2QIfr2BJkNFHEQ2mgdAxzd5yDnAPUTaYl/jTWaJ7iAceg03a/DRzTlT9yTBSU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736343358; c=relaxed/simple; bh=qfy/s5nUhNt/DNVDC1ytDMSKcFurRd9Pbl58V3Ovm/k=; h=Message-ID:Subject:From:To:Date:MIME-Version; b=d1szVjBuP59ckvAHNcmTT+9ftmSa/L/AS+eSbTqpNryTNBryPelvE598GwRoWmkmO1DLgjypktHO7Q1/QtsH0uZIsL2SS9unpubvddCWMAbtD+ve2xHCKRTnp5hG8PkXNVjo5Hz8VTg8Ip6p7CVYj3rvfy4PTTGS58kT+AUNMhI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ADFAA3857B8C Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 2F4C33032F85; Wed, 8 Jan 2025 14:35:57 +0100 (CET) Received: by r6.localdomain (Postfix, from userid 1000) id 9449134019F; Wed, 08 Jan 2025 14:35:56 +0100 (CET) Message-ID: Subject: Re: [PATCH] dwarf2out: Emit DWARF 6 DW_AT_language_{name,version} From: Mark Wielaard To: Jakub Jelinek , Jason Merrill , Richard Biener Cc: gcc-patches@gcc.gnu.org, Alexandra Petlanova Hajkova , gdb@sourceware.org Date: Wed, 08 Jan 2025 14:35:56 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.2 (3.54.2-1.fc41) MIME-Version: 1.0 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Hi Jakub, On Tue, 2025-01-07 at 20:22 +0100, Jakub Jelinek wrote: > DWARF has voted in yesterday https://dwarfstd.org/issues/241209.1.html , > which is basically just a guarantee that the DWARF 6 draft > DW_AT_language_{name,version} attribute codes and content of > https://dwarfstd.org/languages-v6.html can be used as an extension > in DWARF 5 and won't be changed. >=20 > So, this patch is an alternative to the > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html > patch, which had the major problem that it required changing all the > DWARF consumers to be able to debug C17 or later or C++17 or later > sources. Note that most consumers (binutils, gdb, systemtap, valgrind, elfutils) have already been updated to use the new DW_LANG constants. We can easily backport that to the last stable releases before gcc 15 is released. > This patch uses still DWARF 5 DW_LANG_C11 or DW_LANG_C_plus_plus_14, > the latest code in DWARF 5 proper, so all DWARF 5 capable consumers > should be able to deal with that, but additionally emits the > DWARF 6 attributes so that newer DWARF consumers can see it isn't > just C++14 but say C++23 or C11 but C23. Consumers which don't know > those DWARF 6 attributes would just ignore them. This is like any other > -gno-strict-dwarf extension, except that normally we emit say DWARF 5 > codes where possible only after DWARF 5 is released, while in this case > there is a guarantee it can be used before DWARF 6 is released. Code looks ok to me, it is only for C and C++, would be nice to at least get it for Fortran and Ada too. > --- gcc/dwarf2out.cc.jj 2025-01-02 11:23:35.541251268 +0100 > +++ gcc/dwarf2out.cc 2025-01-07 10:09:16.866866563 +0100 > @@ -8755,6 +8755,14 @@ break_out_comdat_types (dw_die_ref die) > unit =3D new_die (DW_TAG_type_unit, NULL, NULL); > add_AT_unsigned (unit, DW_AT_language, > get_AT_unsigned (comp_unit_die (), DW_AT_langua= ge)); > + if (unsigned lname =3D get_AT_unsigned (comp_unit_die (), > + DW_AT_language_name)) > + { > + add_AT_unsigned (unit, DW_AT_language_name, lname); > + add_AT_unsigned (unit, DW_AT_language_version, > + get_AT_unsigned (comp_unit_die (), > + DW_AT_language_version)); > + } This relies on language_name and language_version always being set together. Which is the case in the code at this time. Should we assert that? > @@ -25376,11 +25388,28 @@ gen_compile_unit_die (const char *filena > language =3D DW_LANG_C99; > =20 > if (dwarf_version >=3D 5 /* || !dwarf_strict */) > - if (strcmp (language_string, "GNU C11") =3D=3D 0 > - || strcmp (language_string, "GNU C17") =3D=3D 0 > - || strcmp (language_string, "GNU C23") =3D=3D 0 > - || strcmp (language_string, "GNU C2Y") =3D=3D 0) > - language =3D DW_LANG_C11; > + { > + if (strcmp (language_string, "GNU C11") =3D=3D 0) > + language =3D DW_LANG_C11; > + else if (strcmp (language_string, "GNU C17") =3D=3D 0) > + { > + language =3D DW_LANG_C11; > + lname =3D DW_LNAME_C; > + lversion =3D 201710; > + } > + else if (strcmp (language_string, "GNU C23") =3D=3D 0) > + { > + language =3D DW_LANG_C11; > + lname =3D DW_LNAME_C; > + lversion =3D 202311; > + } > + else if (strcmp (language_string, "GNU C2Y") =3D=3D 0) > + { > + language =3D DW_LANG_C11; > + lname =3D DW_LNAME_C; > + lversion =3D 202500; > + } > + } The use of language_string (lang_hooks.name) is a little clumsy, but already part of the current code. In the future it would be nice to have separate language and version hooks for this. Personally I would just go with the new DW_LANG_C17/C23 language code, they will be supported by consumers when gcc 15 is released. The 00 for the month in C2Y is clever. Does that match the __STDC_VERSION__ defined? > @@ -25392,12 +25421,30 @@ gen_compile_unit_die (const char *filena > language =3D DW_LANG_C_plus_plus_11; > else if (strcmp (language_string, "GNU C++14") =3D=3D 0) > language =3D DW_LANG_C_plus_plus_14; > - else if (strcmp (language_string, "GNU C++17") =3D=3D 0 > - || strcmp (language_string, "GNU C++20") =3D=3D 0 > - || strcmp (language_string, "GNU C++23") =3D=3D 0 > - || strcmp (language_string, "GNU C++26") =3D=3D 0) > - /* For now. */ > - language =3D DW_LANG_C_plus_plus_14; > + else if (strcmp (language_string, "GNU C++17") =3D=3D 0) > + { > + language =3D DW_LANG_C_plus_plus_14; > + lname =3D DW_LNAME_C_plus_plus; > + lversion =3D 201703; > + } > + else if (strcmp (language_string, "GNU C++20") =3D=3D 0) > + { > + language =3D DW_LANG_C_plus_plus_14; > + lname =3D DW_LNAME_C_plus_plus; > + lversion =3D 202002; > + } > + else if (strcmp (language_string, "GNU C++23") =3D=3D 0) > + { > + language =3D DW_LANG_C_plus_plus_14; > + lname =3D DW_LNAME_C_plus_plus; > + lversion =3D 202302; > + } > + else if (strcmp (language_string, "GNU C++26") =3D=3D 0) > + { > + language =3D DW_LANG_C_plus_plus_14; > + lname =3D DW_LNAME_C_plus_plus; > + lversion =3D 202400; > + } Why 202400 and not 202600? Cheers, Mark