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

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

[Li Yu]

gdb.Type.fields() missed handling for anonymous members.

This patch fix it, below are details:

Assume that we have a c source as below:

/////////////////////////////
struct A
{
	int a;
	union {
		int b0;
		int b1;
		union {
			int bb0;
			int bb1;
			union {
				int bbb0;
				int bbb1;
			};
		};
	};
	int c;
	union {
		union {
			int dd0;
			int dd1;
		};
		int d2;
		int d3;
	};
};

int main()
{
   struct A a;
}
////////////////////////////

And have a python gdb script as below:

##########################
v = gdb.parse_and_eval("a")
t = v.type
fields = t.fields()
for f in fields:
    print "[%s]" % f.name, v[f.name]
##########################

Without this patch, above script will print:

[a] -7616
[] {{dd0 = 0, dd1 = 0}, d2 = 0, d3 = 0}
[c] 0
[] {{dd0 = 0, dd1 = 0}, d2 = 0, d3 = 0}

With this patch, above script will print rightly:

[a] -7616
[b0] 32767
[b1] 32767
[bb0] 32767
[bb1] 32767
[bbb0] 32767
[bbb1] 32767
[c] 0
[dd0] 0
[dd1] 0
[d2] 0
[d3] 0

And please note that this patch assumed that Paul's patch in 
http://sourceware.org/ml/gdb-patches/2011-09/msg00546.html is
applied first.

Thanks for Paul's feedback for first version of this patch.

Signed-off-by: Li Yu <raise.sail@gmail.com>

gdb/python/:
2011-09-29  Li Yu  <raise.sail@gmail.com>

	* py-type.c: Add process for anonymous members of struct and union

 py-type.c |   63 +++++++++++++++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 54 insertions(+), 9 deletions(-)

diff --git a/gdb/python/py-type.c b/gdb/python/py-type.c
index 27f8b38..d0d8a94 100644
--- a/gdb/python/py-type.c
+++ b/gdb/python/py-type.c
@@ -56,15 +56,20 @@ typedef struct pyty_field_object
 static PyTypeObject field_object_type;
 
 /* A type iterator object.  */
-typedef struct {
+struct __typy_iterator_object
+{
   PyObject_HEAD
+  /* The iterators for support fields of anonymous field */
+  struct __typy_iterator_object *child;
+  struct __typy_iterator_object *parent;
   /* The current field index.  */
   int field;
   /* What to return.  */
   enum gdbpy_iter_kind kind;
   /* Pointer back to the original source type object.  */
   struct pyty_type_object *source;
-} typy_iterator_object;
+};
+typedef struct __typy_iterator_object typy_iterator_object;
 
 static PyTypeObject type_iterator_object_type;
 
@@ -1201,6 +1206,8 @@ typy_make_iter (PyObject *self, enum gdbpy_iter_kind kind)
   if (typy_iter_obj == NULL)
       return NULL;
 
+  typy_iter_obj->child = NULL;
+  typy_iter_obj->parent = NULL;
   typy_iter_obj->field = 0;
   typy_iter_obj->kind = kind;
   Py_INCREF (self);
-  struct type *type = iter_obj->source->type;
-  int i;
-  PyObject *result;
-  
-  if (iter_obj->field < TYPE_NFIELDS (type))
+  typy_iterator_object *iter_obj = (typy_iterator_object *) self, *child_iter_obj;
+  struct type *type;
+  PyObject *result, *child_pytype;
+  char *name;
+
+  while (iter_obj->child) /* deepest anonymous member first */
+  {
+    iter_obj = iter_obj->child;
+  }
+  type = iter_obj->source->type;
+
+restart:
+  while (iter_obj->field >= TYPE_NFIELDS (type))
+  {
+    iter_obj = iter_obj->parent;
+    if (!iter_obj)
+      return NULL;
+    Py_DECREF(iter_obj->child);
+    iter_obj->child = NULL;
+    type = iter_obj->source->type;
+  }
+
+  name = TYPE_FIELD_NAME (type, iter_obj->field);
+  if (!name)
+    goto abort_clean;
+
+  if (name[0]) /* mostly cases */
     {
       result = make_fielditem (type, iter_obj->field, iter_obj->kind);
       if (result != NULL)
-	iter_obj->field++;
+        iter_obj->field++;
       return result;
     }
 
+  /* handing for anonymous members here */
+  type = TYPE_FIELD_TYPE(type, iter_obj->field++);
+  child_pytype = type_to_type_object(type);
+  if (!child_pytype)
+     goto abort_clean;;
+  child_iter_obj = (typy_iterator_object*)typy_make_iter (child_pytype, iter_obj->kind);
+  iter_obj->child = child_iter_obj;
+  child_iter_obj->parent = iter_obj;
+  iter_obj = child_iter_obj;
+  goto restart;
+
+abort_clean:
+  while (iter_obj->parent)
+  {
+    iter_obj = iter_obj->parent;
+    Py_DECREF(iter_obj->child);
+  }
   return NULL;
 }

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

[Paul Koning]

On Sep 30, 2011, at 6:12 AM, Li Yu wrote:

> ...
> 
> gdb/python/:
> 2011-09-29  Li Yu  <raise.sail@gmail.com>
> 
> 	* py-type.c: Add process for anonymous members of struct and union
> 
> py-type.c |   63 +++++++++++++++++++++++++++++++++++++++++++++++++++++---------
> 1 file changed, 54 insertions(+), 9 deletions(-)
> 
> diff --git a/gdb/python/py-type.c b/gdb/python/py-type.c

For some strange reason your patch comes across all messed up.  Perhaps your mailer is creating trouble.  For one thing, it comes across in Unicode with non-break spaces in it, and spaces at the start of lines are  missing.  I can't apply the patch with the "patch" tool...

> index 27f8b38..d0d8a94 100644
> --- a/gdb/python/py-type.c
> +++ b/gdb/python/py-type.c
> @@ -56,15 +56,20 @@ typedef struct pyty_field_object
> static PyTypeObject field_object_type;
> 
> /* A type iterator object.  */
> -typedef struct {
> +struct __typy_iterator_object
> +{
>   PyObject_HEAD
> +  /* The iterators for support fields of anonymous field */
> +  struct __typy_iterator_object *child;
> +  struct __typy_iterator_object *parent;
>   /* The current field index.  */
>   int field;
>   /* What to return.  */
>   enum gdbpy_iter_kind kind;
>   /* Pointer back to the original source type object.  */
>   struct pyty_type_object *source;
> -} typy_iterator_object;
> +};
> +typedef struct __typy_iterator_object typy_iterator_object;

You could just write that as typedef struct __typy_iterator_object { ... } typy_iterator_object; without the typedef as a separate line.

> 
> static PyTypeObject type_iterator_object_type;
> 
> @@ -1201,6 +1206,8 @@ typy_make_iter (PyObject *self, enum gdbpy_iter_kind kind)
>   if (typy_iter_obj == NULL)
>       return NULL;
> 
> +  typy_iter_obj->child = NULL;
> +  typy_iter_obj->parent = NULL;
>   typy_iter_obj->field = 0;
>   typy_iter_obj->kind = kind;
>   Py_INCREF (self);
> -  struct type *type = iter_obj->source->type;
> -  int i;
> -  PyObject *result;
> -  
> -  if (iter_obj->field < TYPE_NFIELDS (type))

Something strange here.  The diff shows this code directly after the other code in typy_make_iter, but that's not where it is.  The code is actually in typy_iterator_iternext, which is several functions later in the source.  Is "git diff" malfunctioning or is this a cut & paste glitch?

> +  typy_iterator_object *iter_obj = (typy_iterator_object *) self, *child_iter_obj;
> +  struct type *type;
> +  PyObject *result, *child_pytype;
> +  char *name;
> +
> +  while (iter_obj->child) /* deepest anonymous member first */
> +  {
> +    iter_obj = iter_obj->child;
> +  }

> +  type = iter_obj->source->type;
> +
> +restart:
> +  while (iter_obj->field >= TYPE_NFIELDS (type))
> +  {
> +    iter_obj = iter_obj->parent;
> +    if (!iter_obj)
> +      return NULL;
> +    Py_DECREF(iter_obj->child);
> +    iter_obj->child = NULL;
> +    type = iter_obj->source->type;
> +  }
> +

That whole chunk of code would be simpler and probably easier to understand if you wrote it as a recursion rather than a loop.  Something like:

restart:
  if (iter_obj->child)
    {
      result = typy_iterator_iternext (iter_obj->child);
      if (result != NULL)
         return result;
      Py_CLEAR (iter_obj->child);
    }

One benefit is that the "parent" member is no longer needed if you do that.  Then the existing "if (iter_obj->field < TYPE_NFIELDS (type))" would stay, and the code you have under "abort_clean" is also the "stop iteration" code.

> +  name = TYPE_FIELD_NAME (type, iter_obj->field);
> +  if (!name)
> +    goto abort_clean;

Why is this needed?  When is name null as opposed to pointing to an empty string?

> +
> +  if (name[0]) /* mostly cases */
>     {
>       result = make_fielditem (type, iter_obj->field, iter_obj->kind);
>       if (result != NULL)
> -	iter_obj->field++;
> +        iter_obj->field++;
>       return result;
>     }
> 
> +  /* handing for anonymous members here */
> +  type = TYPE_FIELD_TYPE(type, iter_obj->field++);
> +  child_pytype = type_to_type_object(type);
> +  if (!child_pytype)
> +     goto abort_clean;;

Extra semicolon.

> +  child_iter_obj = (typy_iterator_object*)typy_make_iter (child_pytype, iter_obj->kind);

You need an error check (child_iter_obj == NULL) here.

> +  iter_obj->child = child_iter_obj;
> +  child_iter_obj->parent = iter_obj;
> +  iter_obj = child_iter_obj;
> +  goto restart;
> +
> +abort_clean:
> +  while (iter_obj->parent)
> +  {
> +    iter_obj = iter_obj->parent;
> +    Py_DECREF(iter_obj->child);
> +  }

If you use recursion, all this simply becomes Py_CLEAN (iter_obj->child);

>   return NULL;
> }

You need to free iter_obj->child in the iterator destructor.

	paul

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

[Li Yu]

2011/9/30 Paul Koning <paulkoning@comcast.net>:
>
> On Sep 30, 2011, at 6:12 AM, Li Yu wrote:
>
>> ...
>>
>> gdb/python/:
>> 2011-09-29  Li Yu  <raise.sail@gmail.com>
>>
>>       * py-type.c: Add process for anonymous members of struct and union
>>
>> py-type.c |   63 +++++++++++++++++++++++++++++++++++++++++++++++++++++---------
>> 1 file changed, 54 insertions(+), 9 deletions(-)
>>
>> diff --git a/gdb/python/py-type.c b/gdb/python/py-type.c
>
> For some strange reason your patch comes across all messed up.  Perhaps your mailer is creating trouble.  For one thing, it comes across in Unicode with non-break spaces in it, and spaces at the start of lines are  missing.  I can't apply the patch with the "patch" tool...

Sorry for confused patch, it may be triggered by my mis-configured thunderbird.

>
>> index 27f8b38..d0d8a94 100644
>> --- a/gdb/python/py-type.c
>> +++ b/gdb/python/py-type.c
>> @@ -56,15 +56,20 @@ typedef struct pyty_field_object
>> static PyTypeObject field_object_type;
>>
>> /* A type iterator object.  */
>> -typedef struct {
>> +struct __typy_iterator_object
>> +{
>>   PyObject_HEAD
>> +  /* The iterators for support fields of anonymous field */
>> +  struct __typy_iterator_object *child;
>> +  struct __typy_iterator_object *parent;
>>   /* The current field index.  */
>>   int field;
>>   /* What to return.  */
>>   enum gdbpy_iter_kind kind;
>>   /* Pointer back to the original source type object.  */
>>   struct pyty_type_object *source;
>> -} typy_iterator_object;
>> +};
>> +typedef struct __typy_iterator_object typy_iterator_object;
>
> You could just write that as typedef struct __typy_iterator_object { ... } typy_iterator_object; without the typedef as a separate line.
>

OK

>>
>> static PyTypeObject type_iterator_object_type;
>>
>> @@ -1201,6 +1206,8 @@ typy_make_iter (PyObject *self, enum gdbpy_iter_kind kind)
>>   if (typy_iter_obj == NULL)
>>       return NULL;
>>
>> +  typy_iter_obj->child = NULL;
>> +  typy_iter_obj->parent = NULL;
>>   typy_iter_obj->field = 0;
>>   typy_iter_obj->kind = kind;
>>   Py_INCREF (self);
>> -  struct type *type = iter_obj->source->type;
>> -  int i;
>> -  PyObject *result;
>> -
>> -  if (iter_obj->field < TYPE_NFIELDS (type))
>
> Something strange here.  The diff shows this code directly after the other code in typy_make_iter, but that's not where it is.  The code is actually in typy_iterator_iternext, which is several functions later in the source.  Is "git diff" malfunctioning or is this a cut & paste glitch?

It just is the result of "git diff" without any manual changes, my
working system is ubuntu natty, a bug in prebuilt git? ;)

Anyway, I will generate right patch at next time.

>
>> +  typy_iterator_object *iter_obj = (typy_iterator_object *) self, *child_iter_obj;
>> +  struct type *type;
>> +  PyObject *result, *child_pytype;
>> +  char *name;
>> +
>> +  while (iter_obj->child) /* deepest anonymous member first */
>> +  {
>> +    iter_obj = iter_obj->child;
>> +  }
>
>> +  type = iter_obj->source->type;
>> +
>> +restart:
>> +  while (iter_obj->field >= TYPE_NFIELDS (type))
>> +  {
>> +    iter_obj = iter_obj->parent;
>> +    if (!iter_obj)
>> +      return NULL;
>> +    Py_DECREF(iter_obj->child);
>> +    iter_obj->child = NULL;
>> +    type = iter_obj->source->type;
>> +  }
>> +
>
> That whole chunk of code would be simpler and probably easier to understand if you wrote it as a recursion rather than a loop.  Something like:
>
> restart:
>  if (iter_obj->child)
>    {
>      result = typy_iterator_iternext (iter_obj->child);
>      if (result != NULL)
>         return result;
>      Py_CLEAR (iter_obj->child);
>    }
>
> One benefit is that the "parent" member is no longer needed if you do that.  Then the existing "if (iter_obj->field < TYPE_NFIELDS (type))" would stay, and the code you have under "abort_clean" is also the "stop iteration" code.
>
>> +  name = TYPE_FIELD_NAME (type, iter_obj->field);
>> +  if (!name)
>> +    goto abort_clean;
>
> Why is this needed?  When is name null as opposed to pointing to an empty string?
>
>> +
>> +  if (name[0]) /* mostly cases */
>>     {
>>       result = make_fielditem (type, iter_obj->field, iter_obj->kind);
>>       if (result != NULL)
>> -     iter_obj->field++;
>> +        iter_obj->field++;
>>       return result;
>>     }
>>
>> +  /* handing for anonymous members here */
>> +  type = TYPE_FIELD_TYPE(type, iter_obj->field++);
>> +  child_pytype = type_to_type_object(type);
>> +  if (!child_pytype)
>> +     goto abort_clean;;
>
> Extra semicolon.
>
>> +  child_iter_obj = (typy_iterator_object*)typy_make_iter (child_pytype, iter_obj->kind);
>
> You need an error check (child_iter_obj == NULL) here.
>

En, you are right again~

>> +  iter_obj->child = child_iter_obj;
>> +  child_iter_obj->parent = iter_obj;
>> +  iter_obj = child_iter_obj;
>> +  goto restart;
>> +
>> +abort_clean:
>> +  while (iter_obj->parent)
>> +  {
>> +    iter_obj = iter_obj->parent;
>> +    Py_DECREF(iter_obj->child);
>> +  }
>
> If you use recursion, all this simply becomes Py_CLEAN (iter_obj->child);
>

I indeed do not like use recursion in any production code, because of it implies
some problems, e.g. it may bring more function calls at runtime, which
means much
security risk and may use more memory, en, this just is my personal taste.

Of course, you must have more experience on gdb internals, if you decide to use
recursion here, I will agree with you too and would like write a
recursion implementation later.

I will leave about one week, see you later ~

>>   return NULL;
>> }
>
> You need to free iter_obj->child in the iterator destructor.
>

I think that Py_DEFREF(iter_obj->child) should be able to help us
reclaim our allocated iterators here.

>        paul
>
>

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

[Paul Koning]

On Oct 1, 2011, at 10:01 AM, Li Yu wrote:

> 2011/9/30 Paul Koning <paulkoning@comcast.net>:
>> 
>> On Sep 30, 2011, at 6:12 AM, Li Yu wrote:
>> 
>>> ...
>> 
>> That whole chunk of code would be simpler and probably easier to understand if you wrote it as a recursion rather than a loop.  Something like:
>> 
>> restart:
>>  if (iter_obj->child)
>>    {
>>      result = typy_iterator_iternext (iter_obj->child);
>>      if (result != NULL)
>>         return result;
>>      Py_CLEAR (iter_obj->child);
>>    }
>> ...
>> If you use recursion, all this simply becomes Py_CLEAN (iter_obj->child);
>> 
> 
> I indeed do not like use recursion in any production code, because of it implies
> some problems, e.g. it may bring more function calls at runtime, which
> means much
> security risk and may use more memory, en, this just is my personal taste.
> 
> Of course, you must have more experience on gdb internals, if you decide to use
> recursion here, I will agree with you too and would like write a
> recursion implementation later.

I'm not all that experienced on gdb internals.  But, for example, you can see that the standard "ptype" command uses recursion.  If it's ok for regular gdb commands, it should be ok for this case.  The amount of stack space used isn't that high since the stack frames for the functions in question are pretty small.
> 
> I will leave about one week, see you later ~
> 
>>>   return NULL;
>>> }
>> 
>> You need to free iter_obj->child in the iterator destructor.
>> 
> 
> I think that Py_DEFREF(iter_obj->child) should be able to help us
> reclaim our allocated iterators here.

What I meant is that you don't have that code in typy_iterator_dealloc. 

	paul

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

[Tom Tromey]

>>>>> "Li" == Li Yu <raise.sail@gmail.com> writes:

Li> gdb.Type.fields() missed handling for anonymous members.
Li> This patch fix it, below are details:

Thanks.

Do you have a copyright assignment in place?  If not, you will need
one.  Contact me off-list and I will get you started.

Li> Assume that we have a c source as below:

This patch needs a test case; so I suggest converting this into the
right form for the test suite.

Li> +struct __typy_iterator_object

Don't use leading underscores for the name here.

Li> +  typy_iterator_object *iter_obj = (typy_iterator_object *) self, *child_iter_obj;

This line is too long.  Just make a second declaration for child_iter_obj.

Li> +  char *name;

Probably could be const.

Li> +  while (iter_obj->child) /* deepest anonymous member first */
Li> +  {

The braces are in the wrong place for the GNU style.
They should be in 2 more spaces; see the GNU coding standards for details.
This occurs in a couple of places.

Li> +restart:
Li> +  while (iter_obj->field >= TYPE_NFIELDS (type))
Li> +  {
Li> +    iter_obj = iter_obj->parent;
Li> +    if (!iter_obj)
Li> +      return NULL;

This seems strange.  This returns NULL without setting a Python
exception.

Also the reference counting seems odd.  I guess I don't understand why
the typy_iterator_object has references to other iterator objects,
instead of plain gdb state.  References to other objects means that you
at least need to decref them when the iterator object is destroyed.

Li> +    Py_DECREF(iter_obj->child);

Missing space before the paren.  This occurs in a few spots.

Li> +  name = TYPE_FIELD_NAME (type, iter_obj->field);
Li> +  if (!name)
Li> +    goto abort_clean;

Why is this here?  I think you would have to check to be sure that there
is never a NULL field name created by gdb; in which case this should be
some kind of internal error.

Li> +  if (name[0]) /* mostly cases */

I don't understand this comment.  I suggest just deleting it.

Li> +  /* handing for anonymous members here */

Comments in gdb should be full sentences: start with an upper-case
letter, end with a period followed by two spaces.  See GNU standards.

Li> +     goto abort_clean;;

Double semicolon.

Li> +  child_iter_obj = (typy_iterator_object*)typy_make_iter (child_pytype, iter_obj->kind);

Line too long, should be wrapped.  Also a missing space after the first ")".

I don't understand why the iterator iterates into sub-objects.  Why not
just have a flat iterator?  That is, return a field with no name whose
type is some structure, and then let the caller iterate over that type
if need be.

Tom

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

[Paul Koning]

On Oct 4, 2011, at 12:36 PM, Tom Tromey wrote:

> ...
> I don't understand why the iterator iterates into sub-objects.  Why not
> just have a flat iterator?  That is, return a field with no name whose
> type is some structure, and then let the caller iterate over that type
> if need be.
> 
> Tom

That's the current behavior.  Yu showed an example where he wanted to get all the field names so he could then use those to retrieve the fields in a gdb.Value object.  (Value objects don't currently have iterators; I'll propose a patch for that shortly.)

You can certainly do this in Python, for example:

import gdb

def deepkeys (t):
    parent = t.iteritems ()
    child = None
    while True:
	if not child:
	    try:
		k, v = parent.next ()
	    except StopIteration:
		parent = None
		raise
	    if k:
		yield k
		continue
	    child = deepkeys (v.type)
	try:
	    yield child.next ()
	except StopIteration:
	    child = None

(This could be done more elegantly if gdb.Type could be subclassed.)

It's an interesting inconsistency that values can be indexed by field names of nested fields inside anonymous fields, but type cannot.  And the keys() method on a Type right now returns only the top level names.  

	paul

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

[Tom Tromey]

>>>>> "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

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

[Paul Koning]

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

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

[Tom Tromey]

>>>>> "Paul" == Paul Koning <paulkoning@comcast.net> writes:

Paul> So we have:
Paul> 1. Type field lookup: flat
Paul> 2. Type iteration: flat
Paul> 3. Value field lookup: recursive
Paul> 4. [Value iteration: flat]  (not submitted yet)

Paul> And Yu's proposed change makes #2 recursive (but does not change #1).

Paul> I think minimally things need to be pairwise the same (1 and 2, 3 and
Paul> 4).  It seems most logical for all four to be the same.  My preference
Paul> would be all four recursive, but flat/flat, recursive/recursive is a
Paul> reasonable fallback especially if we add sample code for recursive
Paul> walk of gdb.Type to the gdb Python library.

I think making them all 'flat' is probably best.

My reason is that with the proposed patch, I don't think there is a way
to inspect a Type to discover that it has an anonymous field.  But, this
seems like a reasonable thing to want to do.  That is, I think accurate
introspection is more valuable than notational convenience.

I would be in favor of helper functions in gdb.types, though.

Tom

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

[Paul Koning]

On Oct 19, 2011, at 4:49 PM, Tom Tromey wrote:

>>>>>> "Paul" == Paul Koning <paulkoning@comcast.net> writes:
> 
> Paul> So we have:
> Paul> 1. Type field lookup: flat
> Paul> 2. Type iteration: flat
> Paul> 3. Value field lookup: recursive
> Paul> 4. [Value iteration: flat]  (not submitted yet)
> 
> Paul> And Yu's proposed change makes #2 recursive (but does not change #1).
> 
> Paul> I think minimally things need to be pairwise the same (1 and 2, 3 and
> Paul> 4).  It seems most logical for all four to be the same.  My preference
> Paul> would be all four recursive, but flat/flat, recursive/recursive is a
> Paul> reasonable fallback especially if we add sample code for recursive
> Paul> walk of gdb.Type to the gdb Python library.
> 
> I think making them all 'flat' is probably best.
> 
> My reason is that with the proposed patch, I don't think there is a way
> to inspect a Type to discover that it has an anonymous field.  But, this
> seems like a reasonable thing to want to do.  That is, I think accurate
> introspection is more valuable than notational convenience.

So I think that amounts to rejecting Yu's patch.

Also, given my point 3, does that mean we should change val["foo"] so it doesn't recurse down into anonymous fields as it does today?  That would be a change in behavior for an existing feature.

> I would be in favor of helper functions in gdb.types, though.

What did you have in mind?

	paul

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

[Tom Tromey]

>>>>> "Paul" == Paul Koning <paulkoning@comcast.net> writes:

Paul> So I think that amounts to rejecting Yu's patch.

Yeah, I'm afraid so.

Paul> Also, given my point 3, does that mean we should change val["foo"] so
Paul> it doesn't recurse down into anonymous fields as it does today?  That
Paul> would be a change in behavior for an existing feature.

I am not sure about this one :(

>> I would be in favor of helper functions in gdb.types, though.

Paul> What did you have in mind?

The sort of deep iterator you posted earlier.

Tom

[RFA] Python: iterator for deep traversal of gdb.Type struct/union fields

[Paul Koning]

On Oct 20, 2011, at 12:34 PM, Tom Tromey wrote:

>>>>>> "Paul" == Paul Koning <paulkoning@comcast.net> writes:
> 
> Paul> So I think that amounts to rejecting Yu's patch.
> 
> Yeah, I'm afraid so.
> 
> Paul> Also, given my point 3, does that mean we should change val["foo"] so
> Paul> it doesn't recurse down into anonymous fields as it does today?  That
> Paul> would be a change in behavior for an existing feature.
> 
> I am not sure about this one :(
> 
>>> I would be in favor of helper functions in gdb.types, though.
> 
> Paul> What did you have in mind?
> 
> The sort of deep iterator you posted earlier.
> 
> Tom

How about this?

	paul

ChangeLog:

2011-10-25  Paul Koning  <paul_koning@dell.com>

	* python/lib/gdb/types.py (deepitems): New function.
	
testsuite/ChangeLog:

2011-10-25  Paul Koning  <paul_koning@dell.com>

	* gdb.python/lib-types.cc (struct A): New structure.
	* gdb.python/lib-types.exp (deepitems): New tests.

Index: testsuite/gdb.python/lib-types.cc
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/lib-types.cc,v
retrieving revision 1.2
diff -u -r1.2 lib-types.cc
--- testsuite/gdb.python/lib-types.cc	1 Jan 2011 15:33:49 -0000	1.2
+++ testsuite/gdb.python/lib-types.cc	25 Oct 2011 18:22:10 -0000
@@ -54,6 +54,34 @@
 
 enum1 enum1_obj (A);
 
+struct A
+{
+	int a;
+	union {
+		int b0;
+		int b1;
+		union {
+			int bb0;
+			int bb1;
+			union {
+				int bbb0;
+				int bbb1;
+			};
+		};
+	};
+	int c;
+	union {
+		union {
+			int dd0;
+			int dd1;
+		};
+		int d2;
+		int d3;
+	};
+};
+
+struct A a = {1,20,3,40};
+
 int
 main ()
 {
Index: testsuite/gdb.python/lib-types.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/lib-types.exp,v
retrieving revision 1.3
diff -u -r1.3 lib-types.exp
--- testsuite/gdb.python/lib-types.exp	1 Jan 2011 15:33:49 -0000	1.3
+++ testsuite/gdb.python/lib-types.exp	25 Oct 2011 18:22:10 -0000
@@ -138,3 +138,8 @@
 gdb_test_no_output "python enum1_list = enum1_dict.items ()"
 gdb_test_no_output "python enum1_list.sort ()"
 gdb_test "python print enum1_list" {\[\('A', 0L\), \('B', 1L\), \('C', 2L\)\]}
+
+# test deepitems
+gdb_test_no_output "python struct_a = gdb.lookup_type ('struct A')"
+gdb_test "python print struct_a.keys ()" {\['a', '', 'c', ''\]}
+gdb_test "python print \[k for k,v in gdb.types.deepitems(struct_a)\]" {\['a', 'b0', 'b1', 'bb0', 'bb1', 'bbb0', 'bbb1', 'c', 'dd0', 'dd1', 'd2', 'd3'\]}
Index: python/lib/gdb/types.py
===================================================================
RCS file: /cvs/src/src/gdb/python/lib/gdb/types.py,v
retrieving revision 1.2
diff -u -r1.2 types.py
--- python/lib/gdb/types.py	1 Jan 2011 15:33:27 -0000	1.2
+++ python/lib/gdb/types.py	25 Oct 2011 18:22:10 -0000
@@ -89,3 +89,23 @@
         # The enum's value is stored in "bitpos".
         enum_dict[field.name] = field.bitpos
     return enum_dict
+
+
+def deepitems (type_):
+    """Return an iterator that recursively traverses anonymous fields.
+
+    Arguments:
+        type_: The type to traverse.  It should be one of
+        gdb.TYPE_CODE_STRUCT or gdb.TYPE_CODE_UNION.
+
+    Returns:
+        an iterator similar to gdb.Type.iteritems(), i.e., it returns
+        pairs of key, value, but for any anonymous struct or union
+        field that field is traversed recursively, depth-first.
+    """
+    for k, v in type_.iteritems ():
+        if k:
+            yield k, v
+        else:
+            for i in deepitems (v.type):
+                yield i

Re: [RFA] Python: iterator for deep traversal of gdb.Type struct/union fields

[Paul Koning]

On Oct 25, 2011, at 2:23 PM, Paul Koning wrote:

> 
> On Oct 20, 2011, at 12:34 PM, Tom Tromey wrote:
> 
>>>>>>> "Paul" == Paul Koning <paulkoning@comcast.net> writes:
>> 
>> Paul> So I think that amounts to rejecting Yu's patch.
>> 
>> Yeah, I'm afraid so.
>> 
>> Paul> Also, given my point 3, does that mean we should change val["foo"] so
>> Paul> it doesn't recurse down into anonymous fields as it does today?  That
>> Paul> would be a change in behavior for an existing feature.
>> 
>> I am not sure about this one :(
>> 
>>>> I would be in favor of helper functions in gdb.types, though.
>> 
>> Paul> What did you have in mind?
>> 
>> The sort of deep iterator you posted earlier.
>> 
>> Tom
> 
> How about this?

I missed the documentation part for lib/gdb/types.py.  Here is a revised patch that adds the documentation.

	paul

ChangeLog:

2011-10-25  Paul Koning  <paul_koning@dell.com>

	* python/lib/gdb/types.py (deepitems): New function.

testsuite/ChangeLog:
	
2011-10-25  Paul Koning  <paul_koning@dell.com>

	* gdb.python/lib-types.cc (struct A): New structure.
	* gdb.python/lib-types.exp (deepitems): New tests.

doc/ChangeLog:

2011-10-25  Paul Koning  <paul_koning@dell.com>

	* gdb.texinfo (gdb.types): Document new deepitems function.
	
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.881
diff -u -r1.881 gdb.texinfo
--- doc/gdb.texinfo	25 Oct 2011 18:35:19 -0000	1.881
+++ doc/gdb.texinfo	25 Oct 2011 18:50:28 -0000
@@ -24424,6 +24424,34 @@
 
 @item make_enum_dict (@var{enum_type})
 Return a Python @code{dictionary} type produced from @var{enum_type}.
+
+@item deepitems (@var{type})
+Returns a Python iterator similar to the standard
+@code{gdb.Type.iteritems ()} method, except that the iterator returned
+by @code{deepitems} will recursively traverse anonymous struct or
+union fields.  For example:
+
+@smallexample
+struct A
+@{
+    int a;
+    union @{
+        int b0;
+        int b1;
+    @};
+@};
+@end smallexample
+
+Then in gdb:
+@smallexample
+(gdb) python import gdb.types
+(gdb) python struct_a = gdb.lookup_type("struct A")
+(gdb) python print struct_a.keys ()
+@{['a', '']@}
+(gdb) python print [k for k,v in gdb.types.deepitems(struct_a)]
+@{['a', 'b0', 'b1']@}
+@end smallexample
+
 @end table
 
 @node gdb.prompt
Index: python/lib/gdb/types.py
===================================================================
RCS file: /cvs/src/src/gdb/python/lib/gdb/types.py,v
retrieving revision 1.2
diff -u -r1.2 types.py
--- python/lib/gdb/types.py	1 Jan 2011 15:33:27 -0000	1.2
+++ python/lib/gdb/types.py	25 Oct 2011 18:50:28 -0000
@@ -89,3 +89,23 @@
         # The enum's value is stored in "bitpos".
         enum_dict[field.name] = field.bitpos
     return enum_dict
+
+
+def deepitems (type_):
+    """Return an iterator that recursively traverses anonymous fields.
+
+    Arguments:
+        type_: The type to traverse.  It should be one of
+        gdb.TYPE_CODE_STRUCT or gdb.TYPE_CODE_UNION.
+
+    Returns:
+        an iterator similar to gdb.Type.iteritems(), i.e., it returns
+        pairs of key, value, but for any anonymous struct or union
+        field that field is traversed recursively, depth-first.
+    """
+    for k, v in type_.iteritems ():
+        if k:
+            yield k, v
+        else:
+            for i in deepitems (v.type):
+                yield i
Index: testsuite/gdb.python/lib-types.cc
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/lib-types.cc,v
retrieving revision 1.2
diff -u -r1.2 lib-types.cc
--- testsuite/gdb.python/lib-types.cc	1 Jan 2011 15:33:49 -0000	1.2
+++ testsuite/gdb.python/lib-types.cc	25 Oct 2011 18:50:30 -0000
@@ -54,6 +54,34 @@
 
 enum1 enum1_obj (A);
 
+struct A
+{
+	int a;
+	union {
+		int b0;
+		int b1;
+		union {
+			int bb0;
+			int bb1;
+			union {
+				int bbb0;
+				int bbb1;
+			};
+		};
+	};
+	int c;
+	union {
+		union {
+			int dd0;
+			int dd1;
+		};
+		int d2;
+		int d3;
+	};
+};
+
+struct A a = {1,20,3,40};
+
 int
 main ()
 {
Index: testsuite/gdb.python/lib-types.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/lib-types.exp,v
retrieving revision 1.3
diff -u -r1.3 lib-types.exp
--- testsuite/gdb.python/lib-types.exp	1 Jan 2011 15:33:49 -0000	1.3
+++ testsuite/gdb.python/lib-types.exp	25 Oct 2011 18:50:30 -0000
@@ -138,3 +138,8 @@
 gdb_test_no_output "python enum1_list = enum1_dict.items ()"
 gdb_test_no_output "python enum1_list.sort ()"
 gdb_test "python print enum1_list" {\[\('A', 0L\), \('B', 1L\), \('C', 2L\)\]}
+
+# test deepitems
+gdb_test_no_output "python struct_a = gdb.lookup_type ('struct A')"
+gdb_test "python print struct_a.keys ()" {\['a', '', 'c', ''\]}
+gdb_test "python print \[k for k,v in gdb.types.deepitems(struct_a)\]" {\['a', 'b0', 'b1', 'bb0', 'bb1', 'bbb0', 'bbb1', 'c', 'dd0', 'dd1', 'd2', 'd3'\]}

Re: [RFA] Python: iterator for deep traversal of gdb.Type struct/union fields

[Eli Zaretskii]

> From: Paul Koning <paulkoning@comcast.net>
> Date: Tue, 25 Oct 2011 14:54:21 -0400
> Cc: Tom Tromey <tromey@redhat.com>, Li Yu <raise.sail@gmail.com>
> 
> +@item deepitems (@var{type})
> +Returns a Python iterator similar to the standard
> +@code{gdb.Type.iteritems ()} method, except that the iterator returned
                            ^^
Please lose the parentheses.  You just want the method's name, and you
already say that it's a method.  So the parentheses don't add anything
except potential confusion.

> +@end smallexample
> +
> +Then in gdb:

You want @noindent before "Then in gdb", to make it look like
continuation of the previous paragraph, not a beginning of a new one.

Also, please use @value{GDBN} instead of a literal "gdb".

> +(gdb) python import gdb.types

We use @value{GDBP} instead of a literal "(gdb)".

OK with those changes.

Thanks.

Re: [RFA] Python: iterator for deep traversal of gdb.Type struct/union fields

[Paul Koning]

On Oct 25, 2011, at 4:12 PM, Eli Zaretskii wrote:

>> From: Paul Koning <paulkoning@comcast.net>
>> Date: Tue, 25 Oct 2011 14:54:21 -0400
>> Cc: Tom Tromey <tromey@redhat.com>, Li Yu <raise.sail@gmail.com>
>> 
>> +@item deepitems (@var{type})
>> +Returns a Python iterator similar to the standard
>> +@code{gdb.Type.iteritems ()} method, except that the iterator returned
>                            ^^
> Please lose the parentheses.  You just want the method's name, and you
> already say that it's a method.  So the parentheses don't add anything
> except potential confusion.
> 
>> +@end smallexample
>> +
>> +Then in gdb:
> 
> You want @noindent before "Then in gdb", to make it look like
> continuation of the previous paragraph, not a beginning of a new one.
> 
> Also, please use @value{GDBN} instead of a literal "gdb".
> 
>> +(gdb) python import gdb.types
> 
> We use @value{GDBP} instead of a literal "(gdb)".
> 
> OK with those changes.

Thanks.  Committed with those changes.

	paul

Re: [RFA] Python: iterator for deep traversal of gdb.Type struct/union fields

[Doug Evans]

On Wed, Oct 26, 2011 at 8:11 AM, Paul Koning <paulkoning@comcast.net> wrote:
>
> On Oct 25, 2011, at 4:12 PM, Eli Zaretskii wrote:
>
>>> From: Paul Koning <paulkoning@comcast.net>
>>> Date: Tue, 25 Oct 2011 14:54:21 -0400
>>> Cc: Tom Tromey <tromey@redhat.com>, Li Yu <raise.sail@gmail.com>
>>>
>>> +@item deepitems (@var{type})
>>> +Returns a Python iterator similar to the standard
>>> +@code{gdb.Type.iteritems ()} method, except that the iterator returned
>>                            ^^
>> Please lose the parentheses.  You just want the method's name, and you
>> already say that it's a method.  So the parentheses don't add anything
>> except potential confusion.
>>
>>> +@end smallexample
>>> +
>>> +Then in gdb:
>>
>> You want @noindent before "Then in gdb", to make it look like
>> continuation of the previous paragraph, not a beginning of a new one.
>>
>> Also, please use @value{GDBN} instead of a literal "gdb".
>>
>>> +(gdb) python import gdb.types
>>
>> We use @value{GDBP} instead of a literal "(gdb)".
>>
>> OK with those changes.
>
> Thanks.  Committed with those changes.

Hi.  Is it too late to change the name to deep_items?

I like consistency in the user-facing API and we've been using foo_bar
(as does PEP008).

[Or is there a special reason for eliding the underscore?]

TIA

RE: [RFA] Python: iterator for deep traversal of gdb.Type struct/union fields

[Paul_Koning]

>Hi.  Is it too late to change the name to deep_items?
>
>I like consistency in the user-facing API and we've been using foo_bar (as does PEP008).
>
>[Or is there a special reason for eliding the underscore?]

No problem that I know of.  It's a trivial change to make if that's desired.

	paul

Re: [RFA] Python: iterator for deep traversal of gdb.Type struct/union fields

[Tom Tromey]

>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:

>> Hi.  Is it too late to change the name to deep_items?
>> 
>> I like consistency in the user-facing API and we've been using
>> foo_bar (as does PEP008).
>> 
>> [Or is there a special reason for eliding the underscore?]

Paul> No problem that I know of.  It's a trivial change to make if
Paul> that's desired.

Yeah, I think so.

I was unaware that this is in PEP 8.

Also, could you write a NEWS item?  I'd like to try to put all Python
additions into NEWS.

Tom

[RFA] Python: iterator for deep traversal of gdb.Type struct/union fields

[Paul Koning]

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com] 
> Sent: Thursday, October 27, 2011 3:57 PM
> To: Koning, Paul
> Cc: dje@google.com; gdb-patches@sourceware.org
> Subject: Re: [RFA] Python: iterator for deep traversal of gdb.Type struct/union fields
> 
>>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:
> 
>>> Hi.  Is it too late to change the name to deep_items?
>>> 
>>> I like consistency in the user-facing API and we've been using 
>>> foo_bar (as does PEP008).
>>> 
>>> [Or is there a special reason for eliding the underscore?]
> 
> Paul> No problem that I know of.  It's a trivial change to make if 
> Paul> that's desired.
> 
> Yeah, I think so.
> 
> I was unaware that this is in PEP 8.
> 
> Also, could you write a NEWS item?  I'd like to try to put all Python additions into NEWS.

Like this?

	paul

ChangeLog:

2011-10-27  Paul Koning  <paul_koning@dell.com>

	* python/lib/gdb/types.py (deep_items): Rename from deepitems.
	* NEWS: Mention deep_items.

doc/ChangeLog:

2011-10-27  Paul Koning  <paul_koning@dell.com>

	* gdb.texinfo (gdb.types): Rename deepitems to deep_items.

testsuite/ChangeLog:

2011-10-27  Paul Koning  <paul_koning@dell.com>

	* gdb.python/lib-types.exp (deep_items): Rename from deepitems.

Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.461
diff -u -r1.461 NEWS
--- NEWS	24 Oct 2011 11:49:26 -0000	1.461
+++ NEWS	27 Oct 2011 21:21:31 -0000
@@ -56,6 +56,12 @@
   ** A new event "gdb.new_objfile" has been added, triggered by loading a
      new object file.
 
+  ** A new function, "deep_items" has been added to the gdb.types
+     module in the GDB Python modules library.  This function returns
+     an iterator over the fields of a struct or union type.  Unlike
+     the standard Python "iteritems" method, it will recursively traverse
+     any anonymous fields.
+
 * libthread-db-search-path now supports two special values: $sdir and $pdir.
   $sdir specifies the default system locations of shared libraries.
   $pdir specifies the directory where the libpthread used by the application
Index: python/lib/gdb/types.py
===================================================================
RCS file: /cvs/src/src/gdb/python/lib/gdb/types.py,v
retrieving revision 1.3
diff -u -r1.3 types.py
--- python/lib/gdb/types.py	26 Oct 2011 15:09:40 -0000	1.3
+++ python/lib/gdb/types.py	27 Oct 2011 21:21:35 -0000
@@ -91,7 +91,7 @@
     return enum_dict
 
 
-def deepitems (type_):
+def deep_items (type_):
     """Return an iterator that recursively traverses anonymous fields.
 
     Arguments:
@@ -107,5 +107,5 @@
         if k:
             yield k, v
         else:
-            for i in deepitems (v.type):
+            for i in deep_items (v.type):
                 yield i
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.883
diff -u -r1.883 gdb.texinfo
--- doc/gdb.texinfo	27 Oct 2011 11:04:26 -0000	1.883
+++ doc/gdb.texinfo	27 Oct 2011 21:21:35 -0000
@@ -24438,10 +24438,10 @@
 @item make_enum_dict (@var{enum_type})
 Return a Python @code{dictionary} type produced from @var{enum_type}.
 
-@item deepitems (@var{type})
+@item deep_items (@var{type})
 Returns a Python iterator similar to the standard
 @code{gdb.Type.iteritems} method, except that the iterator returned
-by @code{deepitems} will recursively traverse anonymous struct or
+by @code{deep_items} will recursively traverse anonymous struct or
 union fields.  For example:
 
 @smallexample
@@ -24462,7 +24462,7 @@
 (@value{GDBP}) python struct_a = gdb.lookup_type("struct A")
 (@value{GDBP}) python print struct_a.keys ()
 @{['a', '']@}
-(@value{GDBP}) python print [k for k,v in gdb.types.deepitems(struct_a)]
+(@value{GDBP}) python print [k for k,v in gdb.types.deep_items(struct_a)]
 @{['a', 'b0', 'b1']@}
 @end smallexample
 
Index: testsuite/gdb.python/lib-types.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.python/lib-types.exp,v
retrieving revision 1.4
diff -u -r1.4 lib-types.exp
--- testsuite/gdb.python/lib-types.exp	26 Oct 2011 15:10:11 -0000	1.4
+++ testsuite/gdb.python/lib-types.exp	27 Oct 2011 21:21:36 -0000
@@ -139,7 +139,7 @@
 gdb_test_no_output "python enum1_list.sort ()"
 gdb_test "python print enum1_list" {\[\('A', 0L\), \('B', 1L\), \('C', 2L\)\]}
 
-# test deepitems
+# test deep_items
 gdb_test_no_output "python struct_a = gdb.lookup_type ('struct A')"
 gdb_test "python print struct_a.keys ()" {\['a', '', 'c', ''\]}
-gdb_test "python print \[k for k,v in gdb.types.deepitems(struct_a)\]" {\['a', 'b0', 'b1', 'bb0', 'bb1', 'bbb0', 'bbb1', 'c', 'dd0', 'dd1', 'd2', 'd3'\]}
+gdb_test "python print \[k for k,v in gdb.types.deep_items(struct_a)\]" {\['a', 'b0', 'b1', 'bb0', 'bb1', 'bbb0', 'bbb1', 'c', 'dd0', 'dd1', 'd2', 'd3'\]}

Re: [RFA] Python: iterator for deep traversal of gdb.Type struct/union fields

[Eli Zaretskii]

> From: Paul Koning <paulkoning@comcast.net>
> Date: Thu, 27 Oct 2011 17:26:30 -0400
> Cc: Doug Evans <dje@google.com>
> 
> > Also, could you write a NEWS item?  I'd like to try to put all Python additions into NEWS.
> 
> Like this?

Yes, this is fine.  Thanks.

Re: [RFA] Python: iterator for deep traversal of gdb.Type struct/union fields

[Paul Koning]

On Oct 27, 2011, at 6:01 PM, Eli Zaretskii wrote:

>> From: Paul Koning <paulkoning@comcast.net>
>> Date: Thu, 27 Oct 2011 17:26:30 -0400
>> Cc: Doug Evans <dje@google.com>
>> 
>>> Also, could you write a NEWS item?  I'd like to try to put all Python additions into NEWS.
>> 
>> Like this?
> 
> Yes, this is fine.  Thanks.

Done.

	paul