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/16/2015 01:27 PM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: Eli Zaretskii []
>> Sent: Friday, September 11, 2015 11:02 AM
>> To: Pedro Alves
>> Cc: Metzger, Markus T;
>> Subject: Re: [PATCH v2 17/17] infrun: scheduler-locking reverse
>>> Date: Fri, 11 Sep 2015 09:55:41 +0100
>>> From: Pedro Alves <>
>>> CC:
> 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.

> It looks like "replay" mode means that GDB is executing from its (own)
> execution log; "record" mode means that GDB is extending its execution
> log.

That makes sense.

> Traditionally, GDB records when stepping forward from the end of the
> execution log.  On targets that support native reverse-stepping, however,
> GDB is able to extend its execution log also when stepping backward from
> the beginning of GDB's execution log.

Sounds like wishful thinking on the part of the author though then.
I don't think that gdb actually implements that, or ever did.

> This doesn't work with record btrace.

AFAICS, it doesn't work with record-full either.

When you reach the end of the execution log going backwards, and then issue
another back-step, record_full_wait_1 does not try to step backwards any
further, but just immediately returns TARGET_WAITKIND_NO_HISTORY again.

Pedro Alves

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