[PATCH v2 17/17] infrun: scheduler-locking reverse
Pedro Alves
palves@redhat.com
Wed Sep 16 12:54:00 GMT 2015
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
More information about the Gdb-patches
mailing list