Re: [PATCH v2 17/17] infrun: scheduler-locking reverse

[Pedro Alves <palves@redhat.com>]

On 09/16/2015 01:54 PM, Pedro Alves wrote:
> On 09/16/2015 01:27 PM, Metzger, Markus T wrote:
>>> -----Original Message-----
>>> From: Eli Zaretskii [mailto:eliz@gnu.org]
>>> Sent: Friday, September 11, 2015 11:02 AM
>>> To: Pedro Alves
>>> Cc: Metzger, Markus T; gdb-patches@sourceware.org
>>> Subject: Re: [PATCH v2 17/17] infrun: scheduler-locking reverse
>>>
>>>> Date: Fri, 11 Sep 2015 09:55:41 +0100
>>>> From: Pedro Alves <palves@redhat.com>
>>>> CC: gdb-patches@sourceware.org
>>
>> The second paragraph of [1] says "When this [record] target is in use, if the
>> execution log includes the record for the next instruction, gdb will debug in
>> replay mode.".
>>
>> Following this definition of "replay mode", I agree with Eli's first suggestion
>> to call the new scheduler-locking mode "replay".
> 
> Me too.

Actually, there's still one detail, that goes back to what I first asked;
whether we call reverse execution "replay" too.  So it now
sounds clearer to me that when we're reverse debugging with a target
that does native reverse-stepping, where the user is not using
a record/replay target and has not typed "record", etc., we don't
call reverse debugging "replay".  However, the patch had this:

+  else if ((scheduler_mode == schedlock_reverse)
+	   && ((execution_direction == EXEC_REVERSE)
+	       || target_record_is_replaying (minus_one_ptid)))
+    {

That means that the setting is in effect also when reverse debugging
_without_ a record/replay target, e.g., with qemu/simics/etc.
Do we want the setting to take effect with these too, or do we not?
It doesn't a difference in practice today because the RSP packets for
reverse debugging assuming a single threaded target, but once we
support connecting to multiple remote targets at the same time, for
instance, it would come into effect.

Just bringing this up so we make an informed decision.

Thanks,
Pedro Alves