From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19752 invoked by alias); 4 Jan 2004 19:10:21 -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 19745 invoked from network); 4 Jan 2004 19:10:20 -0000 Received: from unknown (HELO moutvdomng.kundenserver.de) (212.227.126.249) by sources.redhat.com with SMTP; 4 Jan 2004 19:10:20 -0000 Received: from [212.227.126.223] (helo=mrelayng.kundenserver.de) by moutvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AdDdB-0000iY-00; Sun, 04 Jan 2004 20:09:45 +0100 Received: from [80.131.66.238] (helo=onlinehome.de) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AdDdB-00073G-00; Sun, 04 Jan 2004 20:09:45 +0100 Message-ID: <3FF87003.3010800@onlinehome.de> Date: Sun, 04 Jan 2004 19:10:00 -0000 From: Christoph Jaeschke User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029 MIME-Version: 1.0 To: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: Proposal: offset based member name (or type) lookup References: <3FF853B5.7020107@onlinehome.de> <20040104172536.GA29473@nevyn.them.org> <20040104173034.GA29603@nevyn.them.org> In-Reply-To: <20040104173034.GA29603@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00037.txt.bz2 Daniel Jacobowitz wrote: > 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. > Sure, I'm interested in contributing. But, because I'm not very familiar with the command interface (that's why ptype was re-used), I would be happy if someone else create a new command and just call the processing func. If Jim or Andrew send me the forms, you will get the patch.