Bail out of processing stop if hook-stop resumes target / changes context
authorPedro Alves <palves@redhat.com>
Mon, 14 Sep 2015 14:45:14 +0000 (15:45 +0100)
committerPedro Alves <palves@redhat.com>
Mon, 14 Sep 2015 14:45:14 +0000 (15:45 +0100)
commit4c2f2a792a5971fcc7fe6511725eaf50d19d302b
tree1bcd3950962a71534108444d1a97e2d77de378f6
parent919e6dbe9b61a27e8f7f89121ba182907df461a3
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.
gdb/ChangeLog
gdb/infrun.c
gdb/infrun.h
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.base/hook-stop-continue.c [deleted file]
gdb/testsuite/gdb.base/hook-stop-continue.exp [deleted file]
gdb/testsuite/gdb.base/hook-stop-frame.c [deleted file]
gdb/testsuite/gdb.base/hook-stop-frame.exp [deleted file]
gdb/testsuite/gdb.base/hook-stop.c [new file with mode: 0644]
gdb/testsuite/gdb.base/hook-stop.exp [new file with mode: 0644]