Re: [PATCH v2] gdb/python: add missing handling for anonymous members of struct and union

[Paul Koning <paulkoning at comcast dot net>]

On Oct 4, 2011, at 4:23 PM, Tom Tromey wrote:

>>>>>> "Paul" == Paul Koning <paulkoning@comcast.net> writes:
> 
> 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 whose
> Tom> type is some structure, and then let the caller iterate over that type
> Tom> if need be.
> 
> 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.
> 
> Ok, I see.  Thanks.
> 
> Paul> (Value objects don't currently have iterators; I'll propose a
> Paul> patch for that shortly.)
> 
> Thanks, after reading your other patch I was meaning to see if this was
> needed :)
> 
> Paul> You can certainly do this in Python, for example:
> 
> Why don't we do that, then, in some code in the gdb python library?
> 
> Paul> (This could be done more elegantly if gdb.Type could be subclassed.)
> 
> It seems reasonable to me.
> 
> Tom

There is an inconsistency between type and value that relates to this discussion.  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 the other hands, for Value objects, you *can* ask for a subfield of an anonymous 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 each key that can be used in an item lookup "obj[key]" is also returned by keys(), 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 fallback especially if we add sample code for recursive walk of gdb.Type to the gdb Python library.

	paul