From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12762 invoked by alias); 4 Jan 2004 17:30:36 -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 12755 invoked from network); 4 Jan 2004 17:30:35 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 4 Jan 2004 17:30:35 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AdC5C-0007iT-CO; Sun, 04 Jan 2004 12:30:34 -0500 Date: Sun, 04 Jan 2004 17:30:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com, Christoph Jaeschke Subject: Re: Proposal: offset based member name (or type) lookup Message-ID: <20040104173034.GA29603@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com, Christoph Jaeschke References: <3FF853B5.7020107@onlinehome.de> <20040104172536.GA29473@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040104172536.GA29473@nevyn.them.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00035.txt.bz2 On Sun, Jan 04, 2004 at 12:25:37PM -0500, Daniel Jacobowitz wrote: > On Sun, Jan 04, 2004 at 06:56:05PM +0100, Christoph Jaeschke wrote: > > Hi, > > > > I would like to propose a offset based member name lookup of > > structs/classes. Assume: > > > > struct X { > > int a; > > int b; > > }; > > > > struct Y { > > struct X x[4]; > > int c; > > }; > > > > struct Z { > > Y y; > > }; > > > > If you apply a patch for gdb 6.0 I've prepared, you can ask gdb by > > > > ptype Z + 28 > > > > about Z's relative name at offset 28 > > > > .y.x[3].b > > > > using > > > > ptype Z+28, typechain > > > > gdb will append also the typechain > > > > .y.x[3].b, typechain = ::Y::X[4]::int > > > > > > There may be a better suited command than 'ptype' for it, it was choosen > > just because it was the simplest way to add it. > > > > The patch contains also a caching mechanism, speeding up a lot if you do > > many lookups in big nested structures. It has a minimal memory > > requirement and will not hurt for single lookups. > > > > The patch can be send if you are interested in. > > Well, I don't like the syntax, but I think this is a wonderful idea. > The other feature I've been meaning to add since forever is a variant > of ptype which shows byte offsets for every field. > > The problem with using ptype is that "Z+28" already has a meaning; gdb > will try to add the two, or call an overloaded + operator in C++, et > cetera. This should probably be a new command; that'll be more useful > for MI anyway. Oh, and I forgot the obligatory followup to this: if you are interested in contributing this patch, and I hope you are, then please file an FSF copyright assignment. Jim or Andrew can send you the appropriate forms to get the process started. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer