[binutils-gdb] fix "stale cleanup" internal-warning when using "catch assert" command

[sergiodj+buildbot@sergiodj.net]

*** TEST RESULTS FOR COMMIT 241db429d5735ae8875e38991c82204b310c2ff5 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: master
Commit: 241db429d5735ae8875e38991c82204b310c2ff5

fix "stale cleanup" internal-warning when using "catch assert" command

Trying to insert a catchpoint on all Ada assertions now triggers
the following internal warning regardless of the situation. For
instance, not even debugging any program:

    (gdb) catch assert
    /[...]/gdb/common/cleanups.c:264: internal-warning:
    restore_my_cleanups has found a stale cleanup

This is due to a small bug in the following C++-ification commit:

    commit bc18fbb575437dd10089ef4619e46c0b9a93097d
    Author: Tom Tromey <tom@tromey.com>
    Date:   Fri May 18 15:58:50 2018 -0600
    Subject: Change ada_catchpoint::excep_string to be a std::string

The stale cleanup in question is the following one in top.c:execute_command:

    cleanup_if_error = make_bpstat_clear_actions_cleanup ();

This cleanup is expected to be discarded if there are no exception.
There were no GDB exception; however, a C++ exception was triggered,
because we passed NULL as the excep_string argument when calling
create_ada_exception_catchpoint, which is a reference to a const
string. So we get a C++ exception during the std::string constructor,
which propagates up, causing the cleanup to unexpectedly remain
in the cleanup chain.

This patch fixes the immediate issue of the incorrect call to
create_ada_exception_catchpoint.

gdb/ChangeLog:

        * ada-lang.c (catch_assert_command): Pass empty string instead
        of NULL for excep_string argument.

Tested on x86_64-linux, fixes the following failures:

  * catch_assert_if.exp: insert catchpoint on failed assertions with condition
  * catch_ex.exp: insert catchpoint on failed assertions

This also fixes about a dozen UNRESOLVED tests that are a consequence
of the two tests above failing and crashing GDB.