Re: Python: add field access by name and standard python mapping methods to gdb.Type

[Phil Muldoon <pmuldoon@redhat.com>]

Paul Koning <paulkoning@comcast.net> writes:

> On Sep 16, 2011, at 6:45 AM, Phil Muldoon wrote:
>
>> Paul Koning <paulkoning@comcast.net> writes:
>> 
>>> ...
>> 
>>> +typy_getitem (PyObject *self, PyObject *key)
>>> +{
>>> +  struct type *type = ((type_object *) self)->type;
>>> +  char *field;
>>> +  int i;
>>> +  
>>> +  field = python_string_to_host_string (key);
>>> +  if (field == NULL)
>>> +    return NULL;
>>> +
>>> +  /* We want just fields of this type, not of base types, so instead of 
>>> +     using lookup_struct_elt_type, portions of that function are
>>> +     copied here.  */
>>> +
>>> +  for (;;)
>>> +    {
>>> +      CHECK_TYPEDEF (type);
>>> +      if (TYPE_CODE (type) != TYPE_CODE_PTR
>>> +	  && TYPE_CODE (type) != TYPE_CODE_REF)
>>> +	break;
>>> +      type = TYPE_TARGET_TYPE (type);
>>> +    }
>> 
>> This gives me pause, not because it is wrong, but because I wonder if
>> there is a possibility that this loop will never exit.  I presume it
>> will eventually find the base_type, just by continually walking the
>> TARGET_TYPE until it reaches bottom.  
>> 
>> Can you check how this is done in other parts of GDB (this must happen
>> quite often?).
>
> This code was directly lifted from lookup_struct_elt_type in gdbtypes.c  The same sort of thing occurs in a number of other places, as you expected.  For example, in c_value_of_variable in varobj.c, a similar loop shows up but that one just strips TYPE_CODE_REF, it does not look for TYPE_CODE_PTR.
>
> I can certainly make this a standard function, perhaps in gdbtypes.c.  Then I can also change other occurrences of this code pattern to call that, but I would not want to go use it for things that are similar but not identical (like the one in varobj.c I mentioned).  Should that be a separate patch?  It seems better that way.
>
> 	paul

Yeah that is fine.  Thanks for checking!

Cheers

Phil