From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24527 invoked by alias); 28 Nov 2013 08:42:44 -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 24517 invoked by uid 89); 28 Nov 2013 08:42:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mga02.intel.com Received: from Unknown (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Nov 2013 08:42:41 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 28 Nov 2013 00:42:32 -0800 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga002.jf.intel.com with ESMTP; 28 Nov 2013 00:42:31 -0800 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; Thu, 28 Nov 2013 08:42:17 +0000 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.135]) by IRSMSX106.ger.corp.intel.com ([169.254.8.15]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 08:42:16 +0000 From: "Metzger, Markus T" To: Jan Kratochvil CC: "gdb-patches@sourceware.org" Subject: RE: [+rfc] Re: [patch v6 00/21] record-btrace: reverse Date: Thu, 28 Nov 2013 10:54:00 -0000 Message-ID: References: <1379676639-31802-1-git-send-email-markus.t.metzger@intel.com> <20131006195913.GA2518@host2.jankratochvil.net> <20131127185727.GA18038@host2.jankratochvil.net> In-Reply-To: <20131127185727.GA18038@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-11/txt/msg00876.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Wednesday, November 27, 2013 7:57 PM > To: Metzger, Markus T > Cc: gdb-patches@sourceware.org > Subject: Re: [+rfc] Re: [patch v6 00/21] record-btrace: reverse >=20 > On Thu, 07 Nov 2013 16:41:40 +0100, Metzger, Markus T wrote: > > I hacked a first prototype of this (see below). It passes most tests b= ut > > results in three fails in the record_goto suite. > > > > One thing that it shows, though, is that it only removes the 'mostly > harmless' > > hack in the various goto functions shown above. > > > > The more serious hacks in record_btrace_start_replaying > > > > /* 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 =3D get_current_frame_nocheck (); > > insn =3D btrace_insn_get (replay); > > sal =3D find_pc_line (insn->pc, 0); > > set_step_info (frame, sal); > > > > and record_btrace_stop_replaying > > > > /* Make sure we're not leaving any stale registers. */ > > registers_changed_ptid (tp->ptid); > > > > however, are not removed by this. >=20 > In such case it is not finished. These hacks should not be needed. See below. > > They are required when reverse-stepping the first time or when > > stepping past the end of the execution trace. >=20 > I have patched what you describe as the problem. But as I do not have a = box > with reliably working BTS so it is difficult for me to say whether it wor= ks or > not. I can look at other problems if you describe them from a reliable b= ox. Those hacks are not related to "record goto" and are thus also not affected by the patch to implement "record goto" via wait/resume. Let me try to describe the problem. It is also exposed by the next.exp tes= t. Assume we enable btrace and next over a function call. We will end up right after the call instruction. (gdb) record btrace=20 (gdb) n 50 return 0; /* main.3 */ (gdb) record instruction-history - 31 0x0000000000400590 : push %rbp 32 0x0000000000400591 : mov %rsp,%rbp 33 0x0000000000400594 : leaveq=20 34 0x0000000000400595 : retq=20=20=20 35 0x000000000040059f : leaveq=20 36 0x00000000004005a0 : retq=20=20=20 37 0x00000000004005af : leaveq=20 38 0x00000000004005b0 : retq=20=20=20 39 0x00000000004005c4 : leaveq=20 40 0x00000000004005c5 : retq=20=20=20 (gdb) disas Dump of assembler code for function main: 0x00000000004005c6 <+0>: push %rbp 0x00000000004005c7 <+1>: mov %rsp,%rbp 0x00000000004005ca <+4>: callq 0x4005b1 =3D> 0x00000000004005cf <+9>: mov $0x0,%eax 0x00000000004005d4 <+14>: leaveq=20 0x00000000004005d5 <+15>: retq=20=20=20 End of assembler dump. (gdb) If we now do a reverse-next, we end up inside the function we were supposed to step over. (gdb) reverse-next fun4 () at record_goto.c:44 44 } /* fun4.5 */ (gdb) record instruction-history - 30 0x000000000040059a : callq 0x400590 31 0x0000000000400590 : push %rbp 32 0x0000000000400591 : mov %rsp,%rbp 33 0x0000000000400594 : leaveq=20 34 0x0000000000400595 : retq=20=20=20 35 0x000000000040059f : leaveq=20 36 0x00000000004005a0 : retq=20=20=20 37 0x00000000004005af : leaveq=20 38 0x00000000004005b0 : retq=20=20=20 39 =3D> 0x00000000004005c4 : leaveq=20 (gdb) disas Dump of assembler code for function fun4: 0x00000000004005b1 <+0>: push %rbp 0x00000000004005b2 <+1>: mov %rsp,%rbp 0x00000000004005b5 <+4>: callq 0x400590 0x00000000004005ba <+9>: callq 0x400596 0x00000000004005bf <+14>: callq 0x4005a1 =3D> 0x00000000004005c4 <+19>: leaveq=20 0x00000000004005c5 <+20>: retq=20=20=20 End of assembler dump. (gdb) The reason is the way how GDB implements next/reverse-next. We store the frame_id of the current frame and do a single-step.=20=20 Then we try to detect stepping into a subroutine by unwinding the stack frames and comparing the frame_id's with our stored frame_id. The stored frame_id has been computed using dwarf2 frame unwind. After single-stepping, we're replaying the recorded execution. The frame_id's are now computed using btrace frame unwind. Our parent's frame_id does not compare equal to the stored frame_id. We fail to detect that we just reverse-stepped into a subroutine. The s/w record implementation does not suffer from this problem because it traces data and is hence able to use the dwarf2 frame unwinder also when replacing. The way I tried to overcome this is to recompute all frame_id's when we start replaying. This will cause us to store a btrace frame_id in the stepping algorithm. Now we are able to detect that we reverse-stepped into a subroutine. Do you have a better idea? 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