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  <palves@redhat.com>

	* common/common-exceptions.c (struct catcher) <exception>: No
	longer a pointer to volatile exception.  Now an exception value.
	<mask>: 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  <palves@redhat.com>

	Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
	instead.

1 files changed, 6 insertions, 3 deletions

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);