From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by sourceware.org (Postfix) with ESMTPS id F3B5C3858C55 for ; Thu, 13 Oct 2022 20:40:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F3B5C3858C55 Received: by mail-io1-xd32.google.com with SMTP id y80so2379463iof.3 for ; Thu, 13 Oct 2022 13:40:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CPQrmo9VQmNck0Iv9n9nZGxyZ80zWhdFj2jeOROKqcE=; b=Vy3qsbZSrwLh+GYlj23OF5P3BAbHrX4YzaVGs5zqC741/p82MEmQx6f2wV+9j8HUlA 9W+NOqkE5IvGy/pDpXatih+s+Vdj47vcVIbQ/RR4al2rQxDqWlJd3v3AY/Hi7ukMkmqH kdV5sNTlYGe9m4OWanjGRupooJHA+jGvut0eQY/oJbLtYit9Fxg3mBsBjB1z0SLPLtbD ataTGC5af23Eez/bgQ3XvNeHonsU6XX4x4eN3qfBL1i3hvCNCP+qrVPdIL8Cypv/G14I 0sDuLPaHX6nS8wDfP+rUXlq4ej8pESwIO2A1m80KStyf+OXAe60K9s6TrY8XUDsYSg4t EVFQ== X-Gm-Message-State: ACrzQf0M9K3jfUstZNY/xGT5sqGbdiOHOERDoR+YyqDPkWm1gcSlNdlO o5XtjUcxfuT+UBuwl9CWwlHhXg== X-Google-Smtp-Source: AMsMyM5Pf6ts3PA9huSARwGXK0fdzzKiCkN2gzlIRQhSXYRw65xrmP8RWFuQuP+mv0Oado0thPLLpA== X-Received: by 2002:a05:6638:4123:b0:363:ce70:87cb with SMTP id ay35-20020a056638412300b00363ce7087cbmr1052926jab.189.1665693657296; Thu, 13 Oct 2022 13:40:57 -0700 (PDT) Received: from murgatroyd (71-211-160-49.hlrn.qwest.net. [71.211.160.49]) by smtp.gmail.com with ESMTPSA id y10-20020a92c74a000000b002f16e7021f6sm231160ilp.22.2022.10.13.13.40.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Oct 2022 13:40:56 -0700 (PDT) From: Tom Tromey To: Tom Tromey Cc: Tom de Vries , gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Fix .gdb_index with Ada References: <20220922202054.2773698-1-tromey@adacore.com> <03994f80-2aa9-e30a-2cab-d458b402e148@suse.de> <8735buqgh2.fsf@tromey.com> X-Attribution: Tom Date: Thu, 13 Oct 2022 14:40:55 -0600 In-Reply-To: <8735buqgh2.fsf@tromey.com> (Tom Tromey's message of "Tue, 11 Oct 2022 13:59:21 -0600") Message-ID: <871qrbpico.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-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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: Thu, 13 Oct 2022 20:41:00 -0000 Tom> [ ... patch ... ] Tom> fixes the FAIL, so is this one of the "rare and not worth supporting" Tom> cases you're referring to? > I thought that was necessary to avoid redundancy in the index, but I see > now it isn't, or at least not in that way. I'm looking again at why the > new indices are larger in general. I looked into this more. Older versions of gdb don't add C++ symbols to the index, so when I diff'd the indexes I saw a lot of "_Z" additions. Locally I've changed this code to skip linkage names for C++ only. I compared the symbols from old and new indexes. In every case (except the one below) I checked, the new gdb seemed more correct. In particular it added inlined functions to the index, and it used the correct name for "enum class" enumerator constants. I did find out that the new index included entries for the linkage names of classes. This isn't generally useful, and they have weird names like "6mumble", so I also have a patch to drop these entries from the cooked index entirely. Tom