From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id guqhEnsAP2c9KjkAWB0awg (envelope-from ) for ; Thu, 21 Nov 2024 04:42:19 -0500 Received: by simark.ca (Postfix, from userid 112) id 38FDD1E255; Thu, 21 Nov 2024 04:42:19 -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=ham 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 4C3291E253 for ; Thu, 21 Nov 2024 04:42:17 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B10323857830 for ; Thu, 21 Nov 2024 09:42:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B10323857830 Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id EE8DA3858414 for ; Thu, 21 Nov 2024 09:41:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EE8DA3858414 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 EE8DA3858414 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=1732182082; cv=none; b=RSY6l7n+k5htG1eL58vTZBmFozggGr4WMmIuhbpJX4xHzKRrGhfWI9DsdaRn+0glq+7q1To56+R1zCnP+QZWUZSaMpvS/bEkyjI8ONUZZMNs5ywCpZbmEE0WOWT1Qt8EFPdaXrF780eEIVeV2OVg8ffJtH7Oe0A9QVOs8VXV0MM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1732182082; c=relaxed/simple; bh=9tXznjT4YbVAfxEeMBzhIaDQCgOYpvpdoCCMDPekt6U=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=SOAwEl7g2HPaGhJWF7lN7MjT6Uv9DAVTY7vpWnnAxxtJaWfuK/SvzQBrnB+LoOsaL8Hs1OD8UXluct3q7UQTOH1Q8eemX+zNZeSrMQdRAUUaqepX9pJZD9MeaXMRZn7RdArqrtPvbGn9Zng2TGHN1my7oWjHba2mTnC/E5HFGcU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EE8DA3858414 Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 0B5E430D0645; Thu, 21 Nov 2024 10:41:18 +0100 (CET) Date: Thu, 21 Nov 2024 10:41:18 +0100 From: Mark Wielaard To: Jakub Jelinek Cc: Jason Merrill , Richard Biener , gcc-patches@gcc.gnu.org, Alexandra Petlanova Hajkova , gdb@sourceware.org Subject: Re: [RFC PATCH] dwarf2out: Use post-DWARF 5 DW_LANG_* codes for -gdwarf-5 -gno-strict-dwarf Message-ID: <20241121094118.GB8439@gnu.wildebeest.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 Thu, Nov 21, 2024 at 10:16:13AM +0100, Jakub Jelinek via Gdb wrote: > From what I can read in gdb, it doesn't seem to care about exact standard > revision, all it cares about is if the TU is C, C++, Fortran, Ada etc. > So, from this POV perhaps we shouldn't switch at all and ignore all the > post-DWARF 5 codes. > Or shall we wait until gdb, elfutils, whatever else actually looks at > DW_AT_language values is changed to handle the new codes and apply this > patch after that (still one would need a new version of gdb/elfutils/etc.)? > Or wait say half a year or year after that support is added in the > consumers? I'll work with Sasha to make sure support is there for binutils, gdb, elfutils and valgrind (patches should be simple) and backport it so those consumers should be ready before end of year. > The DWARF 6 planned scheme was designed exactly to overcome this problem, > consumers that only care if something is C or C++ etc. will be able to > hardcode the code once and if they care for some behavior on something > more specific, they can just compare the version, DW_AT_language_version >= > 201703 for C++ (or < etc.), or for Fortran DW_AT_language_version >= 2008, > ... Which is obviously much nicer. But I think it will be a little confusing to mix pre-DWARF6 (which won't be done before GCC15 releases) with DWARF5. So lets work on that for GCC16. The patch itself looks good to me. Cheers, Mark