This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [+rfc] Re: [patch v6 00/21] record-btrace: reverse
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 11 Dec 2013 20:57:28 +0100
- Subject: Re: [+rfc] Re: [patch v6 00/21] record-btrace: reverse
- Authentication-results: sourceware.org; auth=none
- References: <1379676639-31802-1-git-send-email-markus dot t dot metzger at intel dot com> <20131006195913 dot GA2518 at host2 dot jankratochvil dot net> <A78C989F6D9628469189715575E55B230AA127B9 at IRSMSX104 dot ger dot corp dot intel dot com> <20131127185727 dot GA18038 at host2 dot jankratochvil dot net> <A78C989F6D9628469189715575E55B230AA2DBEE at IRSMSX104 dot ger dot corp dot intel dot com> <20131128211623 dot GA16695 at host2 dot jankratochvil dot net> <A78C989F6D9628469189715575E55B230AA2E5A9 at IRSMSX104 dot ger dot corp dot intel dot com>
On Fri, 29 Nov 2013 15:00:22 +0100, Metzger, Markus T wrote:
> Here I still have problems with multi-threaded inferiors. When I switch to
> a different thread and then "record goto", I get a "No more reverse-execution
> history" error followed by a "Record goto failed" error.
>
> I believe that "record goto" is resuming the wrong thread after I switch away
> from the eventing thread. Curiously, this does not seem to be a problem if
> I do not set tp->control.exception_resume_breapoint. This needs some
> more debugging.
>
>
> On a related topic, when we implement "record goto" via resume/wait, we will
> trigger breakpoints at the target location. This might or might not be desired.
> We do not trigger breakpoints on our way to the record goto target location.
> Again, this might or might not be desired.
>
> Record full's "record goto" command does not trigger breakpoints; neither at
> the target location nor on its way. In fact, record full does not implement
> "record goto" via resume/wait. Instead, it single-steps through its execution
> history in a simple do-while loop, similar to what I am doing in record btrace.
Execution of commands of a breakpoint at the target location is sure a bug,
I did not realize it. Thanks for finding it.
I was now looking how to suppress them but I do not think there is an easy
soltuion. So I think your previous code without resume+wait during goto was
better and the changes should be reverted.
It will hopefully also fix the multi-threading bug above I have not
investigated.
Could you do a hopefully final v8 post?
Thanks,
Jan