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

Paul Koning
2011-09-16T14:55:21Z

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