From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8739 invoked by alias); 15 Dec 2017 07:54:04 -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 8730 invoked by uid 89); 15 Dec 2017 07:54:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Dec 2017 07:54:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 26154116D5C; Fri, 15 Dec 2017 02:54:01 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lp6EFB7I0h5O; Fri, 15 Dec 2017 02:54:01 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B86AD116D31; Fri, 15 Dec 2017 02:54:00 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 62FDE809B7; Fri, 15 Dec 2017 11:53:56 +0400 (+04) Date: Fri, 15 Dec 2017 07:54:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [RFC] regresssion(internal-error) printing subprogram argument Message-ID: <20171215075356.ab5f2wt652agojdk@adacore.com> References: <20171213103655.msbaxfrykc36f4a7@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2017-12/txt/msg00367.txt.bz2 > I gave the "literal" lookup type a try today, and it turns out > not being so bad, I think. See patch below. Thanks! > Thinking through this and experimenting a bit, I think I convinced > myself that with the current symbol tables infrastructure, > it's not literal _linkage_ names that we want to pass down, but > instead literal _search_ names. I.e., notice that I've switched > the lookup_symbol call in question to pass down > SYMBOL_SEARCH_NAME instead of SYMBOL_LINKAGE_NAME. See > comments in symtab.h in the patch. I forgot about how the hashes were calculated, so what you are saying makes sense. I did a round of testing, both with the official testsuite as well as ours, and I confirm what you see: issue fixed with no regression. I reviewed the patch as well, and it looks good. In particular, the choices you made in terms of what type of lookup to do, and what name to pass made sense to me. > The patch is not complete in the sense that there are > symbol-lookup entry points that could be tweaked to pass > down a symbol_name_match_type instead of assuming FULL. > > And also, I know there are places in ada-lang.c that are doing > what you were doing here too (the "<...>" verbatim trick) which > could be adjusted. But at least this fixes your testcase too, > and causes no regressions. So maybe we could do this incrementally > and pass adjust functions to pass around a symbol_name_match_type > as we find a need? Functions that we miss passing down simply > end up behaving like symbols_name_match_type::FULL, as today. I like this approach. I'll try going through ada-lang.c after this change gets in to see if I can spot some of the "<..."> tricks, and simplify them by using the new symbols_name_match_type instead. -- Joel