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.
+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.
/* 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,