This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 09/11/2015 08:00 AM, Eli Zaretskii wrote:
>> From: Markus Metzger <>
>> Cc:, Eli Zaretskii <>
>> Date: Fri, 11 Sep 2015 08:51:38 +0200
>> Record targets behave as if scheduler-locking were on during replay/reverse
>> execution.  Add a new scheduler-locking option "reverse" to make this implicit
>> behaviour explicit.  It behaves like "on" during reverse/replay execution and
>> like "off" during normal execution.
> I suggest to call this value "replay" instead.  "Reverse" has other
> meanings that can interfere with its mnemonic value.

I'll admit that when reviewing this, I also noticed that the setting
applies both when stepping backwards, and when replaying forward,
and wondered whether that would be confusing.

Do we call reverse execution "replay" too?  The docs are a bit confusing
on this, sometimes it looks like we do, sometimes not.  E.g., [1]

  When debugging in the reverse direction, gdb will work in replay mode as
  long as the execution log includes the record for the previous instruction;
  otherwise, it will work in record mode, if the platform supports reverse
  execution, or stop if not.

[1] -

I think the "If the platform supports reverse execution" part is talking
about when the remote target supports reverse debugging directly,
like e.g., Qemu / Simics / VMWare(?).

But then it seems confusing to call reverse stepping "record mode",
as in "if it's rewinding time, what it is recording??".

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]