Re: Python: fetch value when building gdb.Value object

[Paul Koning <paulkoning@comcast.net>]

On Sep 28, 2011, at 3:24 PM, Phil Muldoon wrote:

> Paul Koning <paulkoning@comcast.net> writes:
> 
>> ...
>> Index: python/py-value.c
>> ===================================================================
>> RCS file: /cvs/src/src/gdb/python/py-value.c,v
>> retrieving revision 1.25
>> diff -u -r1.25 py-value.c
>> --- python/py-value.c	27 Jun 2011 19:21:51 -0000	1.25
>> +++ python/py-value.c	21 Sep 2011 15:45:12 -0000
>> ...
> 
>> @@ -1045,7 +1045,15 @@
>> value_to_value_object (struct value *val)
>> {
>>   value_object *val_obj;
>> +  volatile struct gdb_exception except;
>> 
>> +  TRY_CATCH (except, RETURN_MASK_ALL)
>> +    {
> 
> Something that Jan pointed out a few weeks ago, is our exception net is
> too wide, and asked me to review usage of REVIEW_MASK_ALL.  In this
> case, this should probably be RETURN_MASK_ERROR. 

Question on that...

If I use RETURN_MASK_ERROR and control/C is hit, does that mean the currently running code aborts and the outer handler that does have RETURN_MASK_ALL is entered?

If so, most of the Python code seems to be a candidate for RETURN_MASK_ERROR.  One exception is valpy_getitem (in py-value.c) since it has an xfree(value) after the TRY_CATCH but before the GDB_PY_HANDLE_EXCEPTION (outside the TRY_CATCH block, though -- is that right?)

Probably related: I just tried an infinite Python loop and found that control-C had no effect.  I wonder if the Python interpreter is setting up its own control-C trap (quite possibly -- that's a Python exception after all) and we're losing it somewhere along the lines.

	paul