[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb-patches
Subject:    Re: [PATCH] gdb/record-full: disable range stepping when resuming threads
From:       Simon Marchi via Gdb-patches <gdb-patches () sourceware ! org>
Date:       2023-04-28 18:29:57
Message-ID: 836d5b0c-451c-f167-d547-dee6d5f336bd () efficios ! com
[Download RAW message or body]

On 4/28/23 13:33, Keith Seitz wrote:
> On 4/27/23 11:54, Simon Marchi via Gdb-patches wrote:
>> I see these failures, when running with the native-gdbserver of
>> native-extended-gdbserver boards:
>>
>>      Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.exp ...
>>      FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body
>>      FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 5, from function body
>>      FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 GEP call from function body
>>      FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 50 from function body
>>
> 
> Thank you for the explanation. It was simple enough for me to understand. :-)
> 
>> ---
>>   gdb/record-full.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/gdb/record-full.c b/gdb/record-full.c
>> index 15c5b7d682ed..026c309b674c 100644
>> --- a/gdb/record-full.c
>> +++ b/gdb/record-full.c
>> @@ -1094,6 +1094,13 @@ record_full_target::resume (ptid_t ptid, int step, enum gdb_signal signal)
>>         /* Make sure the target beneath reports all signals.  */
>>         target_pass_signals ({});
>>   +      /* Disable range-stepping, forcing the process target to report stops for
>> +     all executed instructions, so we can record them all.  */
>> +      process_stratum_target *proc_target
>> +    = current_inferior ()->process_target ();
>> +      for (thread_info *thread : all_non_exited_threads (proc_target, ptid))
>> +    thread->control.may_range_step = 0;
>> +
>>         this->beneath ()->resume (ptid, step, signal);
>>       }
>>   }
> 
> This makes sense to me, and I've also regression tested it here and detected no
> problems. [You likely have, too, but it's my habit to test (a lot).]

Hi Keith,

Thanks for taking a look.  I'm not 100% sure about the change, but given
that:

 - it makes sense to you
 - it is isolated in the record-full code
 - record-full is somewhat on life support
 - it fixes some annoying failures I'd like to see disappear

... I'll go ahead and push this patch.  If someone thinks there is a
better way to do it, I'll be happy to revisit the fix.

Simon
[prev in list] [next in list] [prev in thread] [next in thread]