displaced_step_fixup may access memory from the wrong inferior/thread

displaced_step_fixup takes an thread to work with, as argument.  OTOH,
gdbarch_displaced_step_fixup fixes up the current thread.  The former
calls the latter without making sure the current thread is the one
that was passed in.  If it is not, then gdbarch_displaced_step_fixup
may e.g., try reading from a running thread, which doesn't work on
some targets, or worse, read memory from the wrong inferior and
succeed.

This is mostly a latent problem currently, as non-stop switches the
current thread to the event thread early in fetch_inferior_event.

Tested on x86_64 Fedora 20.

gdb/
2015-02-10  Pedro Alves  <palves@redhat.com>

	* infrun.c (displaced_step_fixup): Switch to the event thread
	before calling gdbarch_displaced_step_fixup.
This commit is contained in:
Pedro Alves 2015-02-10 19:13:31 +00:00
parent b05ec7a53f
commit b052c4fbf5
2 changed files with 9 additions and 0 deletions

View File

@ -1,3 +1,8 @@
2015-02-10 Pedro Alves <palves@redhat.com>
* infrun.c (displaced_step_fixup): Switch to the event thread
before calling gdbarch_displaced_step_fixup.
2015-02-10 Antoine Tremblay <antoine.tremblay@ericsson.com>
* MAINTAINERS (Write After Approval): Add Antoine Tremblay.

View File

@ -1784,6 +1784,10 @@ displaced_step_fixup (ptid_t event_ptid, enum gdb_signal signal)
/* Did the instruction complete successfully? */
if (signal == GDB_SIGNAL_TRAP)
{
/* Fixup may need to read memory/registers. Switch to the
thread that we're fixing up. */
switch_to_thread (event_ptid);
/* Fix up the resulting state. */
gdbarch_displaced_step_fixup (displaced->step_gdbarch,
displaced->step_closure,