[binutils-gdb] Prepare gdb.python/mi-py-events.exp for Python/MI in separate channels

[sergiodj+buildbot at sergiodj dot net]

*** TEST RESULTS FOR COMMIT 5a069ab36dead610ac759c4b37f6635419f09306 ***

Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: 5a069ab36dead610ac759c4b37f6635419f09306

Prepare gdb.python/mi-py-events.exp for Python/MI in separate channels

Similarly to 5068630ad34dce5fefbe68d70d3a50cd8b92f71e
(gdb.python/py-events.exp and normal_stop observers ordering) [1],
this commit makes the gdb.python/py-mi-events.exp test not rely on
order in which MI and Python observers run, or even on where each
observer sends its output to.

This shows up as a problem when testing with MI running as a separate
terminal, for example, where Python event output and MI output go to
different channels, even.  But in any case, relying on the order in
which observers run is always going to be fragile.

The fix is to save the string output in the handlers in some variables
and then having MI print them explicitly, instead of printing them
directly from the Python events.

Tested on x86_64 Fedora 23.

https://sourceware.org/ml/gdb-patches/2015-07/msg00290.html

gdb/testsuite/ChangeLog:
2016-06-21  Pedro Alves  <palves@redhat.com>

	* gdb.python/py-mi-events-gdb.py (stop_handler_str)
	(cont_handler_str): New.
	(signal_stop_handler): Set stop_handler_str instead of printing to
	stdout.
	(continue_handler): Set cont_handler_str instead of printing to
	stdout.
	* gdb.python/py-mi-events.exp: Ues mi_execute_to instead of
	mi_send_resuming_command.  Print stop_handler_str and
	cont_handler_str instead of expecting the python events print
	directly.