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

[Paul Koning <paulkoning at comcast dot net>]

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