This is the mail archive of the
mailing list for the GDB project.
RE: [patch v4 23/24] record-btrace: add (reverse-)stepping support
- 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: Mon, 30 Sep 2013 09:30:14 +0000
- Subject: RE: [patch v4 23/24] record-btrace: add (reverse-)stepping support
- Authentication-results: sourceware.org; auth=none
- References: <1372842874-28951-1-git-send-email-markus dot t dot metzger at intel dot com> <1372842874-28951-24-git-send-email-markus dot t dot metzger at intel dot com> <20130818190935 dot GR24153 at host2 dot jankratochvil dot net> <A78C989F6D9628469189715575E55B230A9CF4EA at IRSMSX104 dot ger dot corp dot intel dot com> <20130929172416 dot GA15087 at host2 dot jankratochvil dot net>
> -----Original Message-----
> From: email@example.com [mailto:gdb-patches-
> firstname.lastname@example.org] On Behalf Of Jan Kratochvil
> > But this code compares a NORMAL_FRAME from before the step with a
> > BTRACE_FRAME from after the wait. They will always be unequal hence
> > we will never recognize that we just reverse-stepped into a function.
> > When I reset the frame cache, GDB re-computes the stored frame and
> > compares two BTRACE_FRAMEs, which works OK.
> > See above. Alternatively, I might add a special case to frame comparison,
> > but this would be quite ugly, as well. Do you have a better idea?
> +record_btrace_start_replaying (struct thread_info *tp)
> + /* Make sure we're not using any stale registers. */
> + registers_changed_ptid (tp->ptid);
> + /* We just started replaying. The frame id cached for stepping is based
> + on unwinding, not on branch tracing. Recompute it. */
> + frame = get_current_frame_nocheck ();
> + insn = btrace_insn_get (replay);
> + sal = find_pc_line (insn->pc, 0);
> + set_step_info (frame, sal);
> The problem comes from the new commands like "record goto" which
> inferior content without resuming+stopping it.
> Former "record full" could only change history position by "step/reverse-
> (or similar commands) which did resume+stop the inferior.
> To make the "record goto" command friendly to the GDB infrastructure
> expectations I think you should put a temporary breakpoint to the target
> instruction, resume the inferior and simulate stop at the temporary
> I think all the registers_changed_ptid() calls could be removed afterwards.
That would cause quite some overhead if we're moving by a big number
First, we'd single-step instead of just setting the PC. Second, I'd need to
examine all instruction addresses on the way in order to compute the ignore
count of that temporary breakpoint.
Record full needs to single-step in order to restore the memory and
register contents. But for record btrace, this would be completely
artificial. I don't think we should do it this way. Could we maybe polish
my solution so it is more in line with the rest of GDB?
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