From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24050 invoked by alias); 17 Jun 2015 15:46:28 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 24036 invoked by uid 89); 17 Jun 2015 15:46:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 17 Jun 2015 15:46:27 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 06CC32F1468; Wed, 17 Jun 2015 15:46:25 +0000 (UTC) Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5HFkOYK027076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jun 2015 11:46:25 -0400 Message-ID: <55819650.6090809@redhat.com> Date: Wed, 17 Jun 2015 15:46:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Doug Evans CC: gdb-patches@sourceware.org Subject: Re: [RFC] Revisit PR 16253 ("Attempt to use a type name...") References: <001a1135a192a92e3f0518a643d3@google.com> In-Reply-To: <001a1135a192a92e3f0518a643d3@google.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00365.txt.bz2 On 06/16/2015 10:54 AM, Doug Evans wrote: > > This approach is an improvement with no ill effects (that I can see), > so I'm ok with it. > Please add a reference to PR 16253 in the "hack" comment > in the code. > Will do. > Do other callers of symbol_matches_domain need similar treatment? > I was wondering about block_lookup_symbol. Yeah, I wonder about that myself, but I am cautious to commit to that unless I can coverage test it. So far, I've not been able to trigger a failure in any of these. The proposed change is (intentionally) very conservative. While I could be convinced to add it (nearly?) wherever symbol_matches_domain is used, coverage testing will be difficult, if not impossible. [I spent many, many hours doing coverage testing of the completer API change. It was gruesome!] > btw, here's some perf data using the gmonster1-pervasive-typedef.exp > test from my monster testcase generator. Thanks for that! I haven't yet had a go at it this. Keith