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

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

[Luis Machado]

Investigating PR29727, 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 | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
index eac2c5dab94..19e4df33085 100644
--- a/gdb/displaced-stepping.c
+++ b/gdb/displaced-stepping.c
@@ -139,15 +139,20 @@ 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);
 
+  /* 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);
+
   /* 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 +269,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;
-- 
2.25.1

Re: [PATCH] [PR gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr

[Simon Marchi]

On 10/26/22 04:41, Luis Machado via Gdb-patches wrote:
> Investigating PR29727, it was mentioned a particular test used to work on

Typo, 727 <-> 272

> 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 | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
> index eac2c5dab94..19e4df33085 100644
> --- a/gdb/displaced-stepping.c
> +++ b/gdb/displaced-stepping.c
> @@ -139,15 +139,20 @@ 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);
>  
> +  /* 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);

If the implementation under regcache_write_pc needs to look at the
displaced step buffers (like ARM does), it indeed seems like a good idea
for current_thread and copy_insn_closure to be set, so the buffer
information is complete at that point.  However, my worry would be that
if regcache_write_pc throws, for some reason, current_thread stays set
and the buffer will forever stay marked as busy.  Now, when writing the
PC fails, things don't look so good for the debug session, but still it
would be nice to leave the displaced stepping buffer information in good
shape to not make things worse.  If all the displaced step buffers (and
there's just one on ARM) are busy, threads waiting for a displaced step
will be stuck forever.

So, perhaps use a try / catch to clear those fields if an exception is
thrown (or maybe you can find a cleaner solution).

Simon

Re: [PATCH] [PR gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr

[Luis Machado]

Hi,

On 10/28/22 03:42, Simon Marchi wrote:
> 
> 
> On 10/26/22 04:41, Luis Machado via Gdb-patches wrote:
>> Investigating PR29727, it was mentioned a particular test used to work on
> 
> Typo, 727 <-> 272

Fixed.

> 
>> 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 | 15 ++++++++++++---
>>   1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
>> index eac2c5dab94..19e4df33085 100644
>> --- a/gdb/displaced-stepping.c
>> +++ b/gdb/displaced-stepping.c
>> @@ -139,15 +139,20 @@ 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);
>>   
>> +  /* 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);
> 
> If the implementation under regcache_write_pc needs to look at the
> displaced step buffers (like ARM does), it indeed seems like a good idea
> for current_thread and copy_insn_closure to be set, so the buffer
> information is complete at that point.  However, my worry would be that
> if regcache_write_pc throws, for some reason, current_thread stays set
> and the buffer will forever stay marked as busy.  Now, when writing the
> PC fails, things don't look so good for the debug session, but still it
> would be nice to leave the displaced stepping buffer information in good
> shape to not make things worse.  If all the displaced step buffers (and
> there's just one on ARM) are busy, threads waiting for a displaced step
> will be stuck forever.
> 
> So, perhaps use a try / catch to clear those fields if an exception is
> thrown (or maybe you can find a cleaner solution).

Would a scoped restore be cleaner here?

> 
> Simon

Re: [PATCH] [PR gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr

[Luis Machado]

On 10/28/22 10:53, Luis Machado wrote:
> Hi,
> 
> On 10/28/22 03:42, Simon Marchi wrote:
>>
>>
>> On 10/26/22 04:41, Luis Machado via Gdb-patches wrote:
>>> Investigating PR29727, it was mentioned a particular test used to work on
>>
>> Typo, 727 <-> 272
> 
> Fixed.
> 
>>
>>> 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 | 15 ++++++++++++---
>>>   1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
>>> index eac2c5dab94..19e4df33085 100644
>>> --- a/gdb/displaced-stepping.c
>>> +++ b/gdb/displaced-stepping.c
>>> @@ -139,15 +139,20 @@ 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);
>>> +  /* 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);
>>
>> If the implementation under regcache_write_pc needs to look at the
>> displaced step buffers (like ARM does), it indeed seems like a good idea
>> for current_thread and copy_insn_closure to be set, so the buffer
>> information is complete at that point.  However, my worry would be that
>> if regcache_write_pc throws, for some reason, current_thread stays set
>> and the buffer will forever stay marked as busy.  Now, when writing the
>> PC fails, things don't look so good for the debug session, but still it
>> would be nice to leave the displaced stepping buffer information in good
>> shape to not make things worse.  If all the displaced step buffers (and
>> there's just one on ARM) are busy, threads waiting for a displaced step
>> will be stuck forever.
>>
>> So, perhaps use a try / catch to clear those fields if an exception is
>> thrown (or maybe you can find a cleaner solution).
> 
> Would a scoped restore be cleaner here?
> 

Nevermind, that doesn't help us here.

>>
>> Simon
> 

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

[Luis Machado]

v2: Add try/catch block

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.

Guard the code in a try/catch block to handle the case where we can't
write the PC, so as to not leave partial state in the displaced step
machinery.

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

diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
index eac2c5dab94..3b5376cf31b 100644
--- a/gdb/displaced-stepping.c
+++ b/gdb/displaced-stepping.c
@@ -139,15 +139,31 @@ 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);
 
+  /* 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.  */
+  try
+    {
+      regcache_write_pc (regcache, buffer->addr);
+    }
+  catch (const gdb_exception_error &except)
+    {
+      /* 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.  */
+      buffer->current_thread = nullptr;
+      copy_insn_closure = std::move (buffer->copy_insn_closure);
+      return DISPLACED_STEP_PREPARE_STATUS_CANT;
+    }
   /* 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 +280,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;
-- 
2.25.1

Re: [PATCH, v2] [PR gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr

[Simon Marchi]

On 11/2/22 10:33, Luis Machado via Gdb-patches wrote:
> v2: Add try/catch block
> 
> 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.
> 
> Guard the code in a try/catch block to handle the case where we can't
> write the PC, so as to not leave partial state in the displaced step
> machinery.
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272
> ---
>  gdb/displaced-stepping.c | 26 +++++++++++++++++++++++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
> index eac2c5dab94..3b5376cf31b 100644
> --- a/gdb/displaced-stepping.c
> +++ b/gdb/displaced-stepping.c
> @@ -139,15 +139,31 @@ 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);
>  
> +  /* 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.  */
> +  try
> +    {
> +      regcache_write_pc (regcache, buffer->addr);
> +    }
> +  catch (const gdb_exception_error &except)
> +    {
> +      /* 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.  */
> +      buffer->current_thread = nullptr;
> +      copy_insn_closure = std::move (buffer->copy_insn_closure);

The intention would be clearer by just doing:

  buffer->copy_insn_closure.reset ()

> +      return DISPLACED_STEP_PREPARE_STATUS_CANT;

I think we should just let the exception escape,
DISPLACED_STEP_PREPARE_STATUS_CANT isn't meant to convey an error.
Would this work, using make_scope_exit?

  /* 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);

  reset_buffer.release ();

Simon

Re: [PATCH, v2] [PR gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr

[Luis Machado]

On 11/2/22 17:44, Simon Marchi wrote:
> On 11/2/22 10:33, Luis Machado via Gdb-patches wrote:
>> v2: Add try/catch block
>>
>> 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.
>>
>> Guard the code in a try/catch block to handle the case where we can't
>> write the PC, so as to not leave partial state in the displaced step
>> machinery.
>>
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272
>> ---
>>   gdb/displaced-stepping.c | 26 +++++++++++++++++++++++---
>>   1 file changed, 23 insertions(+), 3 deletions(-)
>>
>> diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
>> index eac2c5dab94..3b5376cf31b 100644
>> --- a/gdb/displaced-stepping.c
>> +++ b/gdb/displaced-stepping.c
>> @@ -139,15 +139,31 @@ 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);
>>   
>> +  /* 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.  */
>> +  try
>> +    {
>> +      regcache_write_pc (regcache, buffer->addr);
>> +    }
>> +  catch (const gdb_exception_error &except)
>> +    {
>> +      /* 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.  */
>> +      buffer->current_thread = nullptr;
>> +      copy_insn_closure = std::move (buffer->copy_insn_closure);
> 
> The intention would be clearer by just doing:
> 
>    buffer->copy_insn_closure.reset ()
> 
>> +      return DISPLACED_STEP_PREPARE_STATUS_CANT;
> 
> I think we should just let the exception escape,
> DISPLACED_STEP_PREPARE_STATUS_CANT isn't meant to convey an error.

Wouldn't letting it escape completely abort the single-stepping operation? I was expecting a return of
DISPLACED_STEP_PREPARE_STATUS_CANT to have a fallback of stepping in-place. Isn't that the case?

> Would this work, using make_scope_exit?

Ah, possibly. Let me try that. Thanks for the suggestion.

> 
>    /* 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);
> 
>    reset_buffer.release ();
> 
> Simon

Re: [PATCH, v2] [PR gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr

[Simon Marchi]

On 11/2/22 14:06, Luis Machado wrote:
> On 11/2/22 17:44, Simon Marchi wrote:
>> On 11/2/22 10:33, Luis Machado via Gdb-patches wrote:
>>> v2: Add try/catch block
>>>
>>> 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.
>>>
>>> Guard the code in a try/catch block to handle the case where we can't
>>> write the PC, so as to not leave partial state in the displaced step
>>> machinery.
>>>
>>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272
>>> ---
>>>   gdb/displaced-stepping.c | 26 +++++++++++++++++++++++---
>>>   1 file changed, 23 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
>>> index eac2c5dab94..3b5376cf31b 100644
>>> --- a/gdb/displaced-stepping.c
>>> +++ b/gdb/displaced-stepping.c
>>> @@ -139,15 +139,31 @@ 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);
>>>   +  /* 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.  */
>>> +  try
>>> +    {
>>> +      regcache_write_pc (regcache, buffer->addr);
>>> +    }
>>> +  catch (const gdb_exception_error &except)
>>> +    {
>>> +      /* 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.  */
>>> +      buffer->current_thread = nullptr;
>>> +      copy_insn_closure = std::move (buffer->copy_insn_closure);
>>
>> The intention would be clearer by just doing:
>>
>>    buffer->copy_insn_closure.reset ()
>>
>>> +      return DISPLACED_STEP_PREPARE_STATUS_CANT;
>>
>> I think we should just let the exception escape,
>> DISPLACED_STEP_PREPARE_STATUS_CANT isn't meant to convey an error.
> 
> Wouldn't letting it escape completely abort the single-stepping operation? I was expecting a return of
> DISPLACED_STEP_PREPARE_STATUS_CANT to have a fallback of stepping in-place. Isn't that the case?

Yeah, but I think that's what we want.  Failing to write the PC is an
"abort mission" kind of failure, IMO.  Something is very broken.

DISPLACED_STEP_PREPARE_STATUS_CANT is not equivalent to an errorp, it's "we have
successfully analyzed the instruction and concluded it can't be
displaced-step".  If we wanted to return a status code, I would suggest
to introduce a new one (e.g. DISPLACED_STEP_PREPARE_STATUS_ERROR).  But
I think the exception is fine, this is how other kinds of failure that
happen when resuming are reported, like when we fail to insert
breakpoints.  We arguably are not very good at handling those
gracefully, but that's the problem of this code here.

Simon

Re: [PATCH, v2] [PR gdb/29272] Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr

[Luis Machado]

On 11/2/22 18:22, Simon Marchi wrote:
> On 11/2/22 14:06, Luis Machado wrote:
>> On 11/2/22 17:44, Simon Marchi wrote:
>>> On 11/2/22 10:33, Luis Machado via Gdb-patches wrote:
>>>> v2: Add try/catch block
>>>>
>>>> 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.
>>>>
>>>> Guard the code in a try/catch block to handle the case where we can't
>>>> write the PC, so as to not leave partial state in the displaced step
>>>> machinery.
>>>>
>>>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272
>>>> ---
>>>>    gdb/displaced-stepping.c | 26 +++++++++++++++++++++++---
>>>>    1 file changed, 23 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
>>>> index eac2c5dab94..3b5376cf31b 100644
>>>> --- a/gdb/displaced-stepping.c
>>>> +++ b/gdb/displaced-stepping.c
>>>> @@ -139,15 +139,31 @@ 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);
>>>>    +  /* 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.  */
>>>> +  try
>>>> +    {
>>>> +      regcache_write_pc (regcache, buffer->addr);
>>>> +    }
>>>> +  catch (const gdb_exception_error &except)
>>>> +    {
>>>> +      /* 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.  */
>>>> +      buffer->current_thread = nullptr;
>>>> +      copy_insn_closure = std::move (buffer->copy_insn_closure);
>>>
>>> The intention would be clearer by just doing:
>>>
>>>     buffer->copy_insn_closure.reset ()
>>>
>>>> +      return DISPLACED_STEP_PREPARE_STATUS_CANT;
>>>
>>> I think we should just let the exception escape,
>>> DISPLACED_STEP_PREPARE_STATUS_CANT isn't meant to convey an error.
>>
>> Wouldn't letting it escape completely abort the single-stepping operation? I was expecting a return of
>> DISPLACED_STEP_PREPARE_STATUS_CANT to have a fallback of stepping in-place. Isn't that the case?
> 
> Yeah, but I think that's what we want.  Failing to write the PC is an
> "abort mission" kind of failure, IMO.  Something is very broken.
> 
> DISPLACED_STEP_PREPARE_STATUS_CANT is not equivalent to an errorp, it's "we have
> successfully analyzed the instruction and concluded it can't be
> displaced-step".  If we wanted to return a status code, I would suggest
> to introduce a new one (e.g. DISPLACED_STEP_PREPARE_STATUS_ERROR).  But
> I think the exception is fine, this is how other kinds of failure that
> happen when resuming are reported, like when we fail to insert
> breakpoints.  We arguably are not very good at handling those
> gracefully, but that's the problem of this code here.

Yeah. That's a reasonable point. I was hoping to salvage something from this bad situation and at least
let the user complete a single-stepping.

Let me get a v3 going.

> 
> Simon

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

[Luis Machado]

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(-)

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;
-- 
2.25.1

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

[Simon Marchi]

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

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

[Luis Machado]

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.