displaced_step_fixup may access memory from the wrong inferior/thread
authorPedro Alves <palves@redhat.com>
Tue, 10 Feb 2015 19:13:31 +0000 (19:13 +0000)
committerPedro Alves <palves@redhat.com>
Tue, 10 Feb 2015 19:13:31 +0000 (19:13 +0000)
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.

gdb/ChangeLog
gdb/infrun.c

index 08575ff5015b215786dbc281ef44e8c90740db3d..58df0ca592a0a0a8b413d4e82a431c0ba57270ca 100644 (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.
index 11dcc0ef1fb83a3e7bead66c00d18cfa4c4ae3ab..5770d773e0ac7a81a4d4b78e7a31cbe830e31c59 100644 (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,
This page took 0.05229 seconds and 4 git commands to generate.