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

[Tom Tromey <tromey@redhat.com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Paul> If so, most of the Python code seems to be a candidate for
Paul> RETURN_MASK_ERROR.

Jan> In fact I do not know, it is a Python thing.
Jan> RETURN_MASK_ALL is right if returned PyExc_KeyboardInterrupt will really abort
Jan> any execution of Python code.  It is probably so, as suggested by:
Jan> 	http://docs.python.org/library/exceptions.html#exceptions.KeyboardInterrupt

Jan> RETURN_MASK_ERROR is right otherwise, but only if it is safe to
Jan> longjmp out from a code called by Python.  This may not be true.
Jan> Python may be C++ exceptions throwing safe but it cannot be safe
Jan> for the GDB longjmp exceptions.  But this case would mean Python is
Jan> buggy for CTRL-C on its own so RETURN_MASK_ERROR probably is not
Jan> right.

I think the Python code in GDB should use RETURN_MASK_ALL in all cases.
The C-c case should be turned into PyExc_KeyboardInterrupt.
Other exceptions should either be ignored or turned into the appropriate
Python exception, depending on the situation.

Letting the C-c case longjmp over the Python implementation is bad, I
would imagine it will result in crashes.  Ignoring it is also bad.

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

Jan> Yes, this is the kind of bug from it, thanks for checking it.

I suspect we have to override Python's SIGINT handling.
I haven't investigated.

Jan> 2011-10-01  Jan Kratochvil  <jan.kratochvil@redhat.com>
Jan> 	* python/py-value.c (valpy_getitem): New variable back_to.  Register
Jan> 	xfree of field to it.  Call do_cleanups for it.  Use RETURN_MASK_ERROR
Jan> 	instead of RETURN_MASK_ALL.

This patch runs the cleanups too late.  They have to be done before
GDB_PY_HANDLE_EXCEPTION, as that has an early return in it.  Cleanest is
probably doing it all inside the TRY_CATCH.

Tom