Re: [patch] [python] find_line_pc_range

[Phil Muldoon <pmuldoon at redhat dot com>]

Phil Muldoon <pmuldoon@redhat.com> writes:

>
>> +      start = gdb_py_long_from_longest (start_pc);
>> +      end = gdb_py_long_from_longest (end_pc);
>> +      PyTuple_SET_ITEM (ret_tuple, 0, start);
>> +      PyTuple_SET_ITEM (ret_tuple, 1, end);
>> +    }
>
>>
> Also gdb_py_long_from_longest is macro that points to Py
> Long_FromUnsignedLongLong.  This can also return NULL which indicates a
> failure, so similar to above, you need to check the return and return
> NULL if one of them fails.  If one of them does return NULL, you also
> need to appropriately clean-up previous references that were created in
> Python.  We normally do this by creating a local error: goto.

I read this back, and I thought, I need to explain this a little more
because of the weird reference stealing behaviour of Python
Tuples/Lists.  In a "normal" scenario, if you create a Python object,
and later on some bit of code fails, you need to decrement that object
in your local error block (or later, if the function succeeds).  But
because Py_Tuple "steals" a reference, it takes ownership of that
object, even if the Tuple itself somehow fails.  So in the above case,
if "start" was added ok, but "end" did not, you do not need to decrement
"start", just decrement the tuple.  I think this is one of two Python
APIs that does this, so you don't come across it often.

Cheers,

Phil