From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16696 invoked by alias); 10 Feb 2003 21:17:42 -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 16689 invoked from network); 10 Feb 2003 21:17:41 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 10 Feb 2003 21:17:41 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18iNCC-0008Uc-00 for ; Mon, 10 Feb 2003 17:18:40 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18iLJ5-0005PS-00 for ; Mon, 10 Feb 2003 16:17:39 -0500 Date: Mon, 10 Feb 2003 21:17:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA/symtab: Let search_symbols find exact matches Message-ID: <20030210211739.GA20772@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20030210160107.GA587@nevyn.them.org> <20030210202506.GA17910@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00265.txt.bz2 On Mon, Feb 10, 2003 at 01:15:21PM -0800, David Carlton wrote: > 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.) I am seriously considering raising the C++ issue again. > 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.) Some of that messiness definitely is going to go away, it's on my hit list. But I don't feel like doing it right this moment :) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer