From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 99D7B3949F15 for ; Fri, 16 Sep 2022 11:55:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 99D7B3949F15 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 9936C33BFF; Fri, 16 Sep 2022 11:55:09 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 818171332E; Fri, 16 Sep 2022 11:55:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id gSf8Hh1kJGPXGQAAMHmgww (envelope-from ); Fri, 16 Sep 2022 11:55:09 +0000 Message-ID: <876e3b8c-b251-be35-5e4e-c75be25ea0e4@suse.de> Date: Fri, 16 Sep 2022 13:55:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: GDB 13 Release 2022-09-11 update Content-Language: en-US To: Tom Tromey Cc: Joel Brobecker , gdb-patches@sourceware.org References: <1983cd06-68ec-e4e1-a2aa-200d016773bf@suse.de> <87a670mfa9.fsf@tromey.com> From: Tom de Vries In-Reply-To: <87a670mfa9.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Fri, 16 Sep 2022 11:55:12 -0000 On 9/16/22 00:41, Tom Tromey wrote: > 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. Hmm, I committed 7ab96794115 ("[gdb/symtab] Enable ada .gdb_index"). So my understanding was that it was working, starting gdb 10, at least to the extent that running cc-with-gdb-index didn't show any regressions vs native for ada test-cases. > So, while that is a regression of sorts, since the feature isn't really > usable for Ada in general, Um, can you elaborate a bit on why you think that? > 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. > Yeah, I also try to run cc-with-debug-names target board once in a while and report/fix regressions, and I don't see any ada-specific problems. > 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. The current failure mode is a disfunctional index, and consequently things are not being found, so there are lots of test-suite FAILs. We could refuse to write an index (which would be non-silent), or we could even write an empty index (which could be silent, I think). Thanks, - Tom