From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5490 invoked by alias); 6 Dec 2001 20:42:05 -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 5455 invoked from network); 6 Dec 2001 20:42:04 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 6 Dec 2001 20:42:04 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16C5Lu-0002yt-00; Thu, 06 Dec 2001 15:42:42 -0500 Date: Thu, 06 Dec 2001 12:42:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb@sources.redhat.com Subject: Re: RFC: Formatting of type output Message-ID: <20011206154242.C11234@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb@sources.redhat.com References: <200112061739.LAA11659@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112061739.LAA11659@duracef.shout.net> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00062.txt.bz2 On Thu, Dec 06, 2001 at 11:39:10AM -0600, Michael Elizabeth Chastain wrote: > Good morning Daniel, > > > Does anything mechanical depend on the format of type output, besides our > > testsuite? > > AFAIK, the white-space changes between v2 g++ and v3 g++ haven't > caused any external consumers of this information to break in such a way > that bug reports have reached the gnats database or the gdb mailing > lists. So I would suspect "no". > > > Does anyone have any radically strong feelings about how it > > should be formatted? > > Basically no. I am going to attempt to print types without the use of the demangler, then. If I can get it to work adequately, I'll ask again. > > Similarly, does anyone prefer to have vtbl and vbase pointers explicitly > > printed? > > Are you talking about "ptype *Foo" or "print *pFoo" here? > > At my day job, I use cygwin + gcc 2.95.3 + pthreads + gdb, > and the vtbl pointer is a quick indicator whether a pointer points > to a sane, live object. That is a case of "print *pFoo". OK, that does seem useful. Survey of facts and opinions: - are not part of the explicit data of the class - vary wildly depending on one's compiler. 2.95 has vbase pointers only, 3.0 has vtbl pointers only. - are exceedingly useful to people debugging C++ support or Java support, but not normally useful to people debugging user code. I'm going to lean towards option (B) [suppressing them by default and adding a set flag to show them] when I get around to this. This is at the bottom of my list though. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer