From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by sourceware.org (Postfix) with ESMTPS id B82E838AA275 for ; Thu, 15 Sep 2022 22:41:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B82E838AA275 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw11.mail.unifiedlayer.com (unknown [10.0.90.126]) by progateway6.mail.pro1.eigbox.com (Postfix) with ESMTP id E5DC110044F53 for ; Thu, 15 Sep 2022 22:41:38 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id YxYAoMIZMvlAaYxYAoQTyy; Thu, 15 Sep 2022 22:41:38 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=ItrbzJzg c=1 sm=1 tr=0 ts=6323aa22 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xOM3xZuef0cA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=Rgbv_sLkJjumcyw6KuEA:9 a=ul9cdbp4aOFLsgKbc677:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=kRdc0A32oozZWmKVgyYQNCdUt2wmuM/qFleD2BWEjNU=; b=qAv35I7a6uOL/O6JurFoMv3eC2 XW3j4hr7uN1kUKAw1tLGwChNrUitg4Krw9WIimF1AU7RYvOklAOl4rX7tgoyd/r5RsdsgVRT0lQR6 RlpmLOkMR5aI6Tvg8p5OlAEmT; Received: from c-98-245-160-18.hsd1.co.comcast.net ([98.245.160.18]:57714 helo=prentzel) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oYxYA-004GCx-0o; Thu, 15 Sep 2022 16:41:38 -0600 From: Tom Tromey To: Tom de Vries Cc: Joel Brobecker , gdb-patches@sourceware.org, Tom Tromey Subject: Re: GDB 13 Release 2022-09-11 update References: <1983cd06-68ec-e4e1-a2aa-200d016773bf@suse.de> X-Attribution: Tom Date: Thu, 15 Sep 2022 16:41:34 -0600 In-Reply-To: <1983cd06-68ec-e4e1-a2aa-200d016773bf@suse.de> (Tom de Vries's message of "Wed, 14 Sep 2022 17:58:37 +0200") Message-ID: <87a670mfa9.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 98.245.160.18 X-Source-L: No X-Exim-ID: 1oYxYA-004GCx-0o X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-98-245-160-18.hsd1.co.comcast.net (prentzel) [98.245.160.18]:57714 X-Source-Auth: tom+tromey.com X-Email-Count: 3 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3022.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2022 22:41:58 -0000 Tom> Perhaps it would be worth clarifying the status of support for .gdb_index. Tom> It is the defacto standard for the index cache, but ada support is Tom> broken ( https://sourceware.org/bugzilla/show_bug.cgi?id=29179 ). Tom> Do we want to fix this? Tom> Do we want to deprecate .gdb_index and start using .debug_names for Tom> the index cache? Tom> Or are we fine with the status quo (which then might need documenting)? My impression is that .gdb_index never really worked correctly for Ada. So, while that is a regression of sorts, since the feature isn't really usable for Ada in general, it doesn't seem worthwhile to fix it. I did make .debug_names work for Ada. See commit 3b00ef10a2a ("Add Ada support for .debug_names"). I'm not at my work machine right now but IIRC this is tested internally. As for the overall plan, my view is: * .gdb_index is (or should be) deprecated. It was good but now we can do better. However... * In order to switch over fully, we have to fix the bugs in .debug_names. Fixing the writing side is easy (I have a patch somewhere) but I haven't worked on the reader yet. * Once that is done we could switch over the index cache, but this also requires some more work to handle the situation where the index needs a string that isn't already in .debug_str. I don't mind if this situation is documented. We could even make .gdb_index writing fail for Ada, though it seems to me that for the index cache it is better to just fail silently. Based on the Ada programs I've seen, the new DWARF reader seems plenty fast enough anyway. Tom