From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10131 invoked by alias); 4 Oct 2011 20:41:24 -0000 Received: (qmail 10122 invoked by uid 22791); 4 Oct 2011 20:41:23 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta03.westchester.pa.mail.comcast.net (HELO qmta03.westchester.pa.mail.comcast.net) (76.96.62.32) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Oct 2011 20:41:08 +0000 Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id gbFe1h0031c6gX853kh90y; Tue, 04 Oct 2011 20:41:09 +0000 Received: from [10.127.238.91] ([65.206.2.68]) by omta23.westchester.pa.mail.comcast.net with comcast id gkgw1h00h1U2a2h3jkgya3; Tue, 04 Oct 2011 20:41:06 +0000 Subject: Re: [PATCH v2] gdb/python: add missing handling for anonymous members of struct and union Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Koning In-Reply-To: Date: Tue, 04 Oct 2011 20:41:00 -0000 Cc: Li Yu , gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8595F6.7080004@gmail.com> To: Tom Tromey Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00118.txt.bz2 On Oct 4, 2011, at 4:23 PM, Tom Tromey wrote: >>>>>> "Paul" =3D=3D Paul Koning writes: >=20 > Tom> I don't understand why the iterator iterates into sub-objects. Why = not > Tom> just have a flat iterator? That is, return a field with no name who= se > Tom> type is some structure, and then let the caller iterate over that ty= pe > Tom> if need be. >=20 > Paul> That's the current behavior. Yu showed an example where he wanted > Paul> to get all the field names so he could then use those to retrieve > Paul> the fields in a gdb.Value object. >=20 > Ok, I see. Thanks. >=20 > Paul> (Value objects don't currently have iterators; I'll propose a > Paul> patch for that shortly.) >=20 > Thanks, after reading your other patch I was meaning to see if this was > needed :) >=20 > Paul> You can certainly do this in Python, for example: >=20 > Why don't we do that, then, in some code in the gdb python library? >=20 > Paul> (This could be done more elegantly if gdb.Type could be subclassed.) >=20 > It seems reasonable to me. >=20 > Tom There is an inconsistency between type and value that relates to this discu= ssion. Right now, Type objects can be asked for a field by name, but that = only works for fields at that level (not inside anonymous elements). On th= e other hands, for Value objects, you *can* ask for a subfield of an anonym= ous field by name. It works that way because value_struct_elt recurses into anonymous elements= , while the Type lookup uses code lifted from lookup_struct_elt_type which = does not do so. This ties into how iterators work, because the expected behavior is that ea= ch key that can be used in an item lookup "obj[key]" is also returned by ke= ys(), and similarly for the other list/iterator methods. Right now, that's= true for gdb.Type (top level only is returned). In my test code for Value= iterators it is currently not true (the Value iterators also process only = the top level even though lookup by name digs into anonymous subelements). So we have: 1. Type field lookup: flat 2. Type iteration: flat 3. Value field lookup: recursive 4. [Value iteration: flat] (not submitted yet) And Yu's proposed change makes #2 recursive (but does not change #1). I think minimally things need to be pairwise the same (1 and 2, 3 and 4). = It seems most logical for all four to be the same. My preference would be = all four recursive, but flat/flat, recursive/recursive is a reasonable fall= back especially if we add sample code for recursive walk of gdb.Type to the= gdb Python library. paul