From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24546 invoked by alias); 2 Feb 2004 20:09:19 -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 24539 invoked from network); 2 Feb 2004 20:09:18 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 2 Feb 2004 20:09:18 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AnkNh-0001me-HB; Mon, 02 Feb 2004 15:09:17 -0500 Date: Mon, 02 Feb 2004 20:09:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] function overloading and namespaces Message-ID: <20040202200917.GA6423@nevyn.them.org> Mail-Followup-To: David Carlton , gdb-patches@sources.redhat.com References: 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: 2004-02/txt/msg00029.txt.bz2 On Fri, Jan 30, 2004 at 09:58:13AM -0800, David Carlton wrote: > This teaches GDB's function overloading code about namespaces. It > also tries to clean up the existing code a bit, primarily by breaking > up largish, messy functions into smaller, messy functions. :-( There's > still a lot of cruft there, and it's by no means a perfect > implementation of C++'s overloading rules (Koening lookup? Template > deduction? Hah!), but it's an improvement over what we've got. I have some deep reservations about this overload resolution code. It is, as you say, wildly inaccurate at its best. It would be nice to punt more reliably when it gets confused. If we get an efficient search-symbol-table-by-basename mechanism we may be able to do this. However, before any of that can be a reality, the existing code needs to be cleaned up. > Tested on i686-pc-linux-gnu, four different GCC version/options; no > regressions, the new tests pass on all of them (even stabs, since the > information that we need is generated by buildsym.c). OK to commit? OK. A couple of general comments: > * cp-support.c (cp_func_name): New. I am really sick of the number of variants of this C++ name parsing we are spawning. While the rest of the branch will be some time yet maturing, I will try to merge the relevant pieces of drow-cplus-branch in the very near future. Then we can dispense with this function. I'm also pretty tired of the growth of functions which concatenate names with "::", or tear them apart with cp_find_next_component. We need to use some more efficient structure for describing namespaces than this. My personal hope is that we can un-flatten the symbol table eventually, and have dictionaries per scope. Do I sound bitter? I blame the C++ language. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer