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

[Pedro Alves <palves@redhat.com>]

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.

> 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.

Thanks,
Pedro Alves