From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15447 invoked by alias); 6 Dec 2001 20:54:49 -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 15406 invoked from network); 6 Dec 2001 20:54:47 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 6 Dec 2001 20:54:47 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16C5YE-0003Ds-00; Thu, 06 Dec 2001 15:55:26 -0500 Date: Thu, 06 Dec 2001 12:54:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: RFC: Formatting of type output Message-ID: <20011206155526.A11800@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <20011206120205.A1278@nevyn.them.org> <1659-Thu06Dec2001224222+0200-eliz@is.elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1659-Thu06Dec2001224222+0200-eliz@is.elta.co.il> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00065.txt.bz2 On Thu, Dec 06, 2001 at 10:42:22PM +0200, Eli Zaretskii wrote: > > Date: Thu, 6 Dec 2001 12:02:05 -0500 > > From: Daniel Jacobowitz > > > > That means that, regrettably, they are formatted differently; it is closer > > to the v2 demangler than to the v3 demangler, but different from both > > (classes get prefixed by "class" even in C++, for example). > > Could you please post a few examples how they are different? It's > hard to reason about this without seeing some live examples; I guess > I don't know enough about this problem to figure this out myself. Well, here's an example. v2/stabs: type = class Class { private: int xxx; public: Class & operator=(Class const &); Class(Class const &); Class(void); } v3/stabs (after some patches not yet submitted to eliminate duplicate constructors): (gdb) ptype Class type = class Class { private: int xxx; public: Class & operator=(Class const&); void Class(Class const&); void Class(); } Notice "const &" becomes "const&" and "(void)" becomes "()". For v3/dwarf, though: (gdb) ptype Class type = class Class { private: int xxx; public: Class & operator=(Class const&); Class(class Class &); Class(void); } See the "class Class &"? That's because Class::Class does not have a DW_AT_mips_linkage_name, so we use the method argument printer. class Class is opaque when the constructor is defined (a bug causes us to have lost "const" here, I'll fix it). operator= is still going through the v3 demangler. Worse, do it a second time in the same GDB session: type = class Class { private: int xxx; public: Class & operator=(Class const&); Class(Class &); Class(void); } And now it matches some combination of the other two. I'm still trying to figure out how to suppress "class" properly. And what I'm proposing is to use the method argument printer all the time. If we do that, as it stands now: (gdb) ptype Class type = class Class { private: int xxx; public: Class & operator=(class Class &); Class(Class &); Class(void); } Now the "class Class" bug shows up earlier, and had the qualifiers not been trampled we would have gained a space in front of the & for operator=. > > Does anything mechanical depend on the format of type output, besides our > > testsuite? > > The documentation might include some examples which could need to be > changed. Obviously, this is not a grave problem, but since you > asked... I'll keep it in mind. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer