From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 634D33858407 for ; Thu, 1 Dec 2022 16:06:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 634D33858407 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.64] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 43F001E0D3; Thu, 1 Dec 2022 11:06:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1669910795; bh=RdLdogJO/OL6HU/QPGl0Ajf8I0Nm4C+GjXwjhe50GYk=; h=Date:Subject:To:References:From:In-Reply-To:From; b=hwrA3ymxlceZEU0oCN7xx1nxNICGqXiRkKC1JU9+IpBNsrYrBwXVPCxjJaFycxaE9 R8LDcsgaBSYWRbur/nbdRg0rvHGXYho2qDbtDML2bxKs/VF9pGrZIC09W/zuJerXcu Sco+2Vo9z9nCXdy5vKnRejBcm5BdHQzjHWLOIxwc= Message-ID: <24ea42d1-afe5-f876-b71a-1883d46d8cb4@simark.ca> Date: Thu, 1 Dec 2022 11:06:34 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH 3/3] Add name canonicalization for C Content-Language: fr To: Tom Tromey , gdb-patches@sourceware.org References: <20221107162356.3175221-1-tromey@adacore.com> <20221107162356.3175221-4-tromey@adacore.com> From: Simon Marchi In-Reply-To: <20221107162356.3175221-4-tromey@adacore.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,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 List-Id: On 11/7/22 11:23, Tom Tromey via Gdb-patches wrote: > PR symtab/29105 shows a number of situations where symbol lookup can > result in the expansion of too many CUs. > > What happens is that lookup_signed_typename will try to look up a type > like "signed int". In cooked_index_functions::expand_symtabs_matching, > when looping over languages, the C++ case will canonicalize this type > name to be "int" instead. Then this method will proceed to expand > every CU that has an entry for "int" -- i.e., nearly all of them. A > crucial component of this is that the caller, objfile::lookup_symbol, > does not do this canonicalization, so when it tries to find the symbol > for "signed int", it fails -- causing the loop to continue. > > This patch fixes the problem by introducing name canonicalization for > C. The idea here is that, by making C and C++ agree on the canonical > name when a symbol name can have multiple spellings, we avoid the bad > behavior in objfile::lookup_symbol (and any other such code -- I don't > know if there is any). > > Unlike C++, C only has a few situations where canonicalization is > needed. And, in particular, due to the lack of overloading (thus > avoiding any issues in linespec) and due to the way c-exp.y works, I > think that no canonicalization is needed during symbol lookup -- only > during symtab construction. This explains why lookup_name_info is not > touched. > > The stabs reader is modified on a "best effort" basis. > > The DWARF reader needed one small tweak in dwarf2_name to avoid a > regression in dw2-unusual-field-names.exp. I think this is adequately > explained by the comment, but basically this is a scenario that should > not occur in real code, only the gdb test suite. > > lookup_signed_typename is simplified. It used to search for two > different type names, but now gdb can search just for the canonical > form. > > gdb.dwarf2/enum-type.exp needed a small tweak, because the > canonicalizer turns "unsigned integer" into "unsigned int integer". > It seems better here to use the correct C type name. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105 What's actually happening in the code is a bit over my head, I don't think I could properly review this without spending several days diving into it. But I tested the cases I reported on the bug, and confirm the over-expansion does not happen with the patch applied. Simon