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: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 29 Nov 2013 14:00:22 +0000
- 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>
> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
> Sent: Thursday, November 28, 2013 10:16 PM
Hello Jan,
> Rather than get_current_frame_nocheck I find safer to just temporarily
> switch
> off the executing flag. There are many other checks which make sense
> which
> were omitted.
>
> Calling set_step_info seems needlessly intrusive to me, there is no need to
> re-set tp->current_symtab + tp->current_line. Despite in the moment of
> record_btrace_start_replaying() I see step_frame_id should be the current
> frame id it does not have to be. Such as when we reverse-continue, it will be
> null_frame_id.
I implemented that based on your patches. It works fine, no regressions.
Thanks for helping make that less hacky.
> I still believe inferior should resume + wait if it changes its PC.
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.
Regards,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052