diff mbox series

[v3,PR,gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr

Message ID 20221111093201.747609-1-luis.machado@arm.com
State Committed
Commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679
Headers
Series [v3,PR,gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr |

Commit Message

Luis Machado Nov. 11, 2022, 9:32 a.m. UTC 
  v2: Add try/catch block
v3: Let it throw after all, and make the rollback cleaner.

PR gdb/29272

Investigating PR29272, it was mentioned a particular test used to work on
GDB 10, but it started failing with GDB 11 onwards. I tracked it down to
some displaced stepping improvements on commit
187b041e2514827b9d86190ed2471c4c7a352874.

In particular, one of the corner cases using copy_insn_closure_by_addr got
silently broken. It is hard to spot because it doesn't have any good tests
for it, and the situation is quite specific to the Arm target.

Essentially, the change from the displaced stepping improvements made it so
we could still invoke copy_insn_closure_by_addr correctly to return the
pointer to a copy_insn_closure, but it always returned nullptr due to
the order of the statements in displaced_step_buffer::prepare.

The way it is now, we first write the address of the displaced step buffer
to PC and then save the copy_insn_closure pointer.

The problem is that writing to PC for the Arm target requires figuring
out if the new PC is thumb mode or not.

With no copy_insn_closure data, the logic to determine the thumb mode
during displaced stepping doesn't work, and gives random results that
are difficult to track (SIGILL, SIGSEGV etc).

Fix this by reordering the PC write in displaced_step_buffer::prepare
and, for safety, add an assertion to
displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right
when it sees this invalid situation. If this gets broken again in the
future, it will be easier to spot.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272
---
 gdb/displaced-stepping.c | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

Comments

Simon Marchi Nov. 11, 2022, 12:39 p.m. UTC | #1 
On 11/11/22 04:32, Luis Machado wrote:
> v2: Add try/catch block
> v3: Let it throw after all, and make the rollback cleaner.
> 
> PR gdb/29272
> 
> Investigating PR29272, it was mentioned a particular test used to work on
> GDB 10, but it started failing with GDB 11 onwards. I tracked it down to
> some displaced stepping improvements on commit
> 187b041e2514827b9d86190ed2471c4c7a352874.
> 
> In particular, one of the corner cases using copy_insn_closure_by_addr got
> silently broken. It is hard to spot because it doesn't have any good tests
> for it, and the situation is quite specific to the Arm target.
> 
> Essentially, the change from the displaced stepping improvements made it so
> we could still invoke copy_insn_closure_by_addr correctly to return the
> pointer to a copy_insn_closure, but it always returned nullptr due to
> the order of the statements in displaced_step_buffer::prepare.
> 
> The way it is now, we first write the address of the displaced step buffer
> to PC and then save the copy_insn_closure pointer.
> 
> The problem is that writing to PC for the Arm target requires figuring
> out if the new PC is thumb mode or not.
> 
> With no copy_insn_closure data, the logic to determine the thumb mode
> during displaced stepping doesn't work, and gives random results that
> are difficult to track (SIGILL, SIGSEGV etc).
> 
> Fix this by reordering the PC write in displaced_step_buffer::prepare
> and, for safety, add an assertion to
> displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right
> when it sees this invalid situation. If this gets broken again in the
> future, it will be easier to spot.
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272

LGTM, thanks:

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Simon
Luis Machado Nov. 11, 2022, 12:48 p.m. UTC | #2 
On 11/11/22 12:39, Simon Marchi wrote:
> On 11/11/22 04:32, Luis Machado wrote:
>> v2: Add try/catch block
>> v3: Let it throw after all, and make the rollback cleaner.
>>
>> PR gdb/29272
>>
>> Investigating PR29272, it was mentioned a particular test used to work on
>> GDB 10, but it started failing with GDB 11 onwards. I tracked it down to
>> some displaced stepping improvements on commit
>> 187b041e2514827b9d86190ed2471c4c7a352874.
>>
>> In particular, one of the corner cases using copy_insn_closure_by_addr got
>> silently broken. It is hard to spot because it doesn't have any good tests
>> for it, and the situation is quite specific to the Arm target.
>>
>> Essentially, the change from the displaced stepping improvements made it so
>> we could still invoke copy_insn_closure_by_addr correctly to return the
>> pointer to a copy_insn_closure, but it always returned nullptr due to
>> the order of the statements in displaced_step_buffer::prepare.
>>
>> The way it is now, we first write the address of the displaced step buffer
>> to PC and then save the copy_insn_closure pointer.
>>
>> The problem is that writing to PC for the Arm target requires figuring
>> out if the new PC is thumb mode or not.
>>
>> With no copy_insn_closure data, the logic to determine the thumb mode
>> during displaced stepping doesn't work, and gives random results that
>> are difficult to track (SIGILL, SIGSEGV etc).
>>
>> Fix this by reordering the PC write in displaced_step_buffer::prepare
>> and, for safety, add an assertion to
>> displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right
>> when it sees this invalid situation. If this gets broken again in the
>> future, it will be easier to spot.
>>
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272
> 
> LGTM, thanks:
> 
> Approved-By: Simon Marchi <simon.marchi@efficios.com>
> 
> Simon

Thanks. Pushed now.
diff mbox series

Patch

diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
index eac2c5dab94..7dfd63d8716 100644
--- a/gdb/displaced-stepping.c
+++ b/gdb/displaced-stepping.c
@@ -139,15 +139,33 @@  displaced_step_buffers::prepare (thread_info *thread, CORE_ADDR &displaced_pc)
       return DISPLACED_STEP_PREPARE_STATUS_CANT;
     }
 
-  /* Resume execution at the copy.  */
-  regcache_write_pc (regcache, buffer->addr);
-
   /* This marks the buffer as being in use.  */
   buffer->current_thread = thread;
 
   /* Save this, now that we know everything went fine.  */
   buffer->copy_insn_closure = std::move (copy_insn_closure);
 
+  /* Reset the displaced step buffer state if we failed to write PC.
+     Otherwise we will prevent this buffer from being used, as it will
+     always have a thread in buffer->current_thread.  */
+  auto reset_buffer = make_scope_exit
+    ([buffer] ()
+      {
+	buffer->current_thread = nullptr;
+	buffer->copy_insn_closure.reset ();
+      });
+
+  /* Adjust the PC so it points to the displaced step buffer address that will
+     be used.  This needs to be done after we save the copy_insn_closure, as
+     some architectures (Arm, for one) need that information so they can adjust
+     other data as needed.  In particular, Arm needs to know if the instruction
+     being executed in the displaced step buffer is thumb or not.  Without that
+     information, things will be very wrong in a random way.  */
+  regcache_write_pc (regcache, buffer->addr);
+
+  /* PC update successful.  Discard the displaced step state rollback.  */
+  reset_buffer.release ();
+
   /* Tell infrun not to try preparing a displaced step again for this inferior if
      all buffers are taken.  */
   thread->inf->displaced_step_state.unavailable = true;
@@ -264,7 +282,11 @@  displaced_step_buffers::copy_insn_closure_by_addr (CORE_ADDR addr)
   for (const displaced_step_buffer &buffer : m_buffers)
     {
       if (addr == buffer.addr)
+      {
+	/* The closure information should always be available. */
+	gdb_assert (buffer.copy_insn_closure.get () != nullptr);
 	return buffer.copy_insn_closure.get ();
+      }
     }
 
   return nullptr;