From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16095 invoked by alias); 10 Feb 2003 21:15:23 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16088 invoked from network); 10 Feb 2003 21:15:23 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 10 Feb 2003 21:15:23 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h1ALFLF04883; Mon, 10 Feb 2003 13:15:21 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA/symtab: Let search_symbols find exact matches References: <20030210160107.GA587@nevyn.them.org> <20030210202506.GA17910@nevyn.them.org> From: David Carlton Date: Mon, 10 Feb 2003 21:15:00 -0000 In-Reply-To: <20030210202506.GA17910@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00264.txt.bz2 On Mon, 10 Feb 2003 15:25:06 -0500, Daniel Jacobowitz said: > There are like a million ways in GDB to find a list of symbols. Me, > I think that's a recipe for suffering. They're all subtly > different. I want the same set of symbols considered for overload > resolution and tab completion, and there's no reason that this > should be different from the results of "break". I intend some day > to condense them all. Yup. I'm just nervous about this for a couple of reasons: 1) If functions try to handle too many situations, they get ugly; I'm still in recovery from trying to deal with find_overload_match, for example. On the other hand, duplicated code is ugly, too. And we're programming in C, which limits our options. I don't know how to best resolve this tension in this particular case; I doubt I'll be thrilled with whatever outcome we end up with. (Unless cleaning this mess takes long enough that we end up porting GDB to C++ first, though even that would only go so far in this instance.) 2) I don't understand search_symbols yet; it's a lot messier than make_symbol_overload_list. Based on some reading of the code and on my experience with cleaning up lookup_symbol_aux, I expect that much of that messiness doesn't need to be there. I'd be happier if somebody (you, me, some other foolhardy person who wants to be initiated into the mysteries of GDB's symbol-management "logic") cleaned up search_symbols first. That way, we could have an informed opinion about the differences between search_symbols and make_symbol_overload_list before merging them. (And I suspect that the differences would shrink over the course of that cleanup, making the merge easier.) But, of course, this is just a reflection of my programming style; different people could reasonably come to a different conclusion on this matter. David Carlton carlton@math.stanford.edu