From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10284 invoked by alias); 30 Sep 2013 09:30:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 10210 invoked by uid 89); 30 Sep 2013 09:30:23 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Sep 2013 09:30:23 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mga02.intel.com Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 30 Sep 2013 02:30:19 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga001.jf.intel.com with ESMTP; 30 Sep 2013 02:30:16 -0700 Received: from irsmsx106.ger.corp.intel.com (163.33.3.31) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 30 Sep 2013 10:30:15 +0100 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.69]) by IRSMSX106.ger.corp.intel.com ([169.254.8.226]) with mapi id 14.03.0123.003; Mon, 30 Sep 2013 10:30:15 +0100 From: "Metzger, Markus T" To: Jan Kratochvil CC: "gdb-patches@sourceware.org" Subject: RE: [patch v4 23/24] record-btrace: add (reverse-)stepping support Date: Mon, 30 Sep 2013 09:30:00 -0000 Message-ID: References: <1372842874-28951-1-git-send-email-markus.t.metzger@intel.com> <1372842874-28951-24-git-send-email-markus.t.metzger@intel.com> <20130818190935.GR24153@host2.jankratochvil.net> <20130929172416.GA15087@host2.jankratochvil.net> In-Reply-To: <20130929172416.GA15087@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg01001.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.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 > now > > compares two BTRACE_FRAMEs, which works OK. > [...] > > See above. Alternatively, I might add a special case to frame comparis= on, > > but this would be quite ugly, as well. Do you have a better idea? >=20 > +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 bas= ed > + on unwinding, not on branch tracing. Recompute it. */ > + frame =3D get_current_frame_nocheck (); > + insn =3D btrace_insn_get (replay); > + sal =3D find_pc_line (insn->pc, 0); > + set_step_info (frame, sal); >=20 > The problem comes from the new commands like "record goto" which > change > inferior content without resuming+stopping it. >=20 > Former "record full" could only change history position by "step/reverse- > step" > (or similar commands) which did resume+stop the inferior. >=20 > 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 > breakpoint. >=20 > I think all the registers_changed_ptid() calls could be removed afterward= s. That would cause quite some overhead if we're moving by a big number of instructions. 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? 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