This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Python: add field access by name and standard python mapping methods to gdb.Type
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