From 492d29ea1c9a8b2c7d5193908119a4e27c045687 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Sat, 7 Mar 2015 15:14:14 +0000 Subject: Split TRY_CATCH into TRY + CATCH This patch splits the TRY_CATCH macro into three, so that we go from this: ~~~ volatile gdb_exception ex; TRY_CATCH (ex, RETURN_MASK_ERROR) { } if (ex.reason < 0) { } ~~~ to this: ~~~ TRY { } CATCH (ex, RETURN_MASK_ERROR) { } END_CATCH ~~~ Thus, we'll be getting rid of the local volatile exception object, and declaring the caught exception in the catch block. This allows reimplementing TRY/CATCH in terms of C++ exceptions when building in C++ mode, while still allowing to build GDB in C mode (using setjmp/longjmp), as a transition step. TBC, after this patch, is it _not_ valid to have code between the TRY and the CATCH blocks, like: TRY { } // some code here. CATCH (ex, RETURN_MASK_ERROR) { } END_CATCH Just like it isn't valid to do that with C++'s native try/catch. By switching to creating the exception object inside the CATCH block scope, we can get rid of all the explicitly allocated volatile exception objects all over the tree, and map the CATCH block more directly to C++'s catch blocks. The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was done with a script, rerun from scratch at every rebase, no manual editing involved. After the mechanical conversion, a few places needed manual intervention, to fix preexisting cases where we were using the exception object outside of the TRY_CATCH block, and cases where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH after this patch]. The result was folded into this patch so that GDB still builds at each incremental step. END_CATCH is necessary for two reasons: First, because we name the exception object in the CATCH block, which requires creating a scope, which in turn must be closed somewhere. Declaring the exception variable in the initializer field of a for block, like: #define CATCH(EXCEPTION, mask) \ for (struct gdb_exception EXCEPTION; \ exceptions_state_mc_catch (&EXCEPTION, MASK); \ EXCEPTION = exception_none) would avoid needing END_CATCH, but alas, in C mode, we build with C90, which doesn't allow mixed declarations and code. Second, because when TRY/CATCH are wired to real C++ try/catch, as long as we need to handle cleanup chains, even if there's no CATCH block that wants to catch the exception, we need for stop at every frame in the unwind chain and run cleanups, then rethrow. That will be done in END_CATCH. After we require C++, we'll still need TRY/CATCH/END_CATCH until cleanups are completely phased out -- TRY/CATCH in C++ mode will save/restore the current cleanup chain, like in C mode, and END_CATCH catches otherwise uncaugh exceptions, runs cleanups and rethrows, so that C++ cleanups and exceptions can coexist. IMO, this still makes the TRY/CATCH code look a bit more like a newcomer would expect, so IMO worth it even if we weren't considering C++. gdb/ChangeLog. 2015-03-07 Pedro Alves * common/common-exceptions.c (struct catcher) : No longer a pointer to volatile exception. Now an exception value. : Delete field. (exceptions_state_mc_init): Remove all parameters. Adjust. (exceptions_state_mc): No longer pop the catcher here. (exceptions_state_mc_catch): New function. (throw_exception): Adjust. * common/common-exceptions.h (exceptions_state_mc_init): Remove all parameters. (exceptions_state_mc_catch): Declare. (TRY_CATCH): Rename to ... (TRY): ... this. Remove EXCEPTION and MASK parameters. (CATCH, END_CATCH): New. All callers adjusted. gdb/gdbserver/ChangeLog: 2015-03-07 Pedro Alves Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH instead. --- gdb/python/py-linetable.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'gdb/python/py-linetable.c') diff --git a/gdb/python/py-linetable.c b/gdb/python/py-linetable.c index ff1716b..195a8b3 100644 --- a/gdb/python/py-linetable.c +++ b/gdb/python/py-linetable.c @@ -172,18 +172,21 @@ ltpy_get_pcs_for_line (PyObject *self, PyObject *args) linetable_entry_object *result; VEC (CORE_ADDR) *pcs = NULL; PyObject *tuple; - volatile struct gdb_exception except; LTPY_REQUIRE_VALID (self, symtab); if (! PyArg_ParseTuple (args, GDB_PY_LL_ARG, &py_line)) return NULL; - TRY_CATCH (except, RETURN_MASK_ALL) + TRY { pcs = find_pcs_for_symtab_line (symtab, py_line, &best_entry); } - GDB_PY_HANDLE_EXCEPTION (except); + CATCH (except, RETURN_MASK_ALL) + { + GDB_PY_HANDLE_EXCEPTION (except); + } + END_CATCH tuple = build_line_table_tuple_from_pcs (py_line, pcs); VEC_free (CORE_ADDR, pcs); -- cgit v1.1