From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32096 invoked by alias); 26 Nov 2003 22:28:42 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32086 invoked from network); 26 Nov 2003 22:28:40 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 26 Nov 2003 22:28:40 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AP89G-0002bo-4k; Wed, 26 Nov 2003 17:28:38 -0500 Date: Wed, 26 Nov 2003 22:28:00 -0000 From: Daniel Jacobowitz To: Ian Lance Taylor Cc: Michael Elizabeth Chastain , gdb@sources.redhat.com Subject: Re: C++/Java regressions Message-ID: <20031126222837.GA5007@nevyn.them.org> Mail-Followup-To: Ian Lance Taylor , Michael Elizabeth Chastain , gdb@sources.redhat.com References: <20031126214341.626764B40B@berman.michael-chastain.com> 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-11/txt/msg00272.txt.bz2 On Wed, Nov 26, 2003 at 05:21:43PM -0500, Ian Lance Taylor wrote: > mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes: > > > ian> Yes, I think it should print A::bar without the const. I have the > > ian> patch in my sources, but I haven't checked it in yet. > > > > But what about: > > > > class Foo > > { > > public: > > int method (); > > int method () const; > > }; > > > > If the name comes back as "Foo::method" then we have ambiguity > > in gdb's output. > > > > I think the const looks ugly and the code that prints the function > > name is also ugly. But I don't wanna print the same name for two > > different methods. > > I have probably lost the context of the question. I am only talking > about the case where DMGL_PARAMS is not passed. In that case, the > demangler will indeed print `Foo::method' for both of your examples. > For that matter, it will also print `Foo::method' for `int method > (int);'. > > If DMGL_PARAMS is passed, then the demangler will print > `Foo::method()' and `Foo::method() const' as usual. > > I think that is appropriate. Without DMGL_PARAMS, you can't > distinguish any Foo::method overloaded based on parameter types. So > it seems logical to me that you also shouldn't be able to distinguish > overloading based on the method qualifier. And that is how the V2 > demangler behaved when DMGL_PARAMS was not passed. > > Does that make sense? It does make sense, but I see Michael's concern. If you look at the complete GDB output in this case, you get roughly: Stopped at breakpoint 1, A::bar () for A::bar() Stopped at breakpoint 1, A::bar () for A::bar() const Stopped at breakpoint 1, A::bar (a = 1) for A::bar(int) I still think the demangler should return A::bar. If we want GDB's output to be unambiguous then GDB is the right place to print the const. Without debug info we may not have it... but who really cares? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer