[binutils-gdb] Bail out of processing stop if hook-stop resumes target / changes context

[sergiodj+buildbot at redhat dot com]

*** TEST RESULTS FOR COMMIT 4c2f2a792a5971fcc7fe6511725eaf50d19d302b ***

Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: 4c2f2a792a5971fcc7fe6511725eaf50d19d302b

Bail out of processing stop if hook-stop resumes target / changes context

This patch, relative to a tree with
https://sourceware.org/ml/gdb-patches/2015-08/msg00295.html, fixes
issues/crashes that trigger if something unexpected happens during a
hook-stop.

E.g., if the inferior disappears while running the hook-stop, we hit
failed assertions:

 (gdb) define hook-stop
 Type commands for definition of "hook-stop".
 End with a line saying just "end".
 >kill
 >end
 (gdb) si
 Kill the program being debugged? (y or n) [answered Y; input not from terminal]
 /home/pedro/gdb/mygit/build/../src/gdb/thread.c:88: internal-error: inferior_thread: Assertion `tp' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n)

I noticed that if a hook-stop issues a synchronous execution command,
we print the same stop event twice:

 (gdb) define hook-stop
 Type commands for definition of "hook-stop".
 End with a line saying just "end".
 >si
 >end
 (gdb) si
 0x000000000040074a      42          args[i] = 1; /* Init value.  */  <<<<<<< once
 0x000000000040074a      42          args[i] = 1; /* Init value.  */  <<<<<<< twice
 (gdb)

In MI:

 *stopped,reason="end-stepping-range",frame={addr="0x000000000040074a",func="main",args=[],file="threads.c",fullname="/home/pedro/gdb/tests/threads.c",line="42"},thread-id="1",stopped-threads="all",core="0"
 *stopped,reason="end-stepping-range",frame={addr="0x000000000040074a",func="main",args=[],file="threads.c",fullname="/home/pedro/gdb/tests/threads.c",line="42"},thread-id="1",stopped-threads="all",core="0"
 (gdb)

The fix has GDB stop processing the event if the context changed.  I
don't expect people to be doing crazy things from the hook-stop.
E.g., it gives me headaches to try to come up a proper behavior for
handling a thread change from a hook-stop... (E.g., imagine the
hook-stop does thread N; step, with scheduler-locing on).  I think the
most important bit here is preventing crashes.

The patch adds a new hook-stop.exp test that covers the above and also
merges in the old hook-stop-continue.exp and hook-stop-frame.exp into
the same framework.

gdb/ChangeLog:
2015-09-14  Pedro Alves  <palves@redhat.com>

	* infrun.c (current_stop_id): New global.
	(get_stop_id, new_stop_id): New functions.
	(fetch_inferior_event): Handle normal_stop proceeding the target.
	(struct stop_context): New.
	(save_stop_context, release_stop_context_cleanup)
	(stop_context_changed): New functions.
	(normal_stop): Return true if the hook-stop changes the stop
	context.
	* infrun.h (get_stop_id): Declare.
	(normal_stop): Now returns int.  Add documentation.

gdb/testsuite/ChangeLog:
2015-09-14  Pedro Alves  <palves@redhat.com>

	* gdb.base/hook-stop-continue.c: Delete.
	* gdb.base/hook-stop-continue.exp: Delete.
	* gdb.base/hook-stop-frame.c: Delete.
	* gdb.base/hook-stop-frame.exp: Delete.
	* gdb.base/hook-stop.c: New file.
	* gdb.base/hook-stop.exp: New file.