From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1436 invoked by alias); 27 Feb 2004 21:09:54 -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 1393 invoked from network); 27 Feb 2004 21:09:53 -0000 Received: from unknown (HELO moutvdomng.kundenserver.de) (212.227.126.249) by sources.redhat.com with SMTP; 27 Feb 2004 21:09:53 -0000 Received: from [212.227.126.223] (helo=mrvdomng.kundenserver.de) by moutvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AwpF3-0004HT-00 for gdb@sources.redhat.com; Fri, 27 Feb 2004 22:09:53 +0100 Received: from [80.131.76.190] (helo=onlinehome.de) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AwpF2-0005ft-00 for gdb@sources.redhat.com; Fri, 27 Feb 2004 22:09:53 +0100 Message-ID: <403FC0A3.1080505@onlinehome.de> Date: Fri, 27 Feb 2004 21:09:00 -0000 From: Christoph Jaeschke User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: Proposal: offset based member name (or type) lookup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00422.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. I did filed a copyright assignment form now. The patch can be send, no problem, but perhaps there should be consensus about the user interface. Should a new command name be created? Is the typechain print ok? Christoph Jaeschke