This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v2 17/17] infrun: scheduler-locking reverse
- From: Pedro Alves <palves at redhat dot com>
- To: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>, Eli Zaretskii <eliz at gnu dot org>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 16 Sep 2015 13:54:17 +0100
- Subject: Re: [PATCH v2 17/17] infrun: scheduler-locking reverse
- Authentication-results: sourceware.org; auth=none
- References: <1441954298-25298-1-git-send-email-markus dot t dot metzger at intel dot com> <1441954298-25298-18-git-send-email-markus dot t dot metzger at intel dot com> <83io7h4eze dot fsf at gnu dot org> <55F2970D dot 6040603 at redhat dot com> <838u8d49d3 dot fsf at gnu dot org> <A78C989F6D9628469189715575E55B23331AE858 at IRSMSX104 dot ger dot corp dot intel dot com>
On 09/16/2015 01:27 PM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: Eli Zaretskii [mailto:firstname.lastname@example.org]
>> Sent: Friday, September 11, 2015 11:02 AM
>> To: Pedro Alves
>> Cc: Metzger, Markus T; email@example.com
>> Subject: Re: [PATCH v2 17/17] infrun: scheduler-locking reverse
>>> Date: Fri, 11 Sep 2015 09:55:41 +0100
>>> From: Pedro Alves <firstname.lastname@example.org>
>>> CC: email@example.com
> The second paragraph of  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".
> It looks like "replay" mode means that GDB is executing from its (own)
> execution log; "record" mode means that GDB is extending its execution
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.