From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123516 invoked by alias); 16 Sep 2015 12:28:10 -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 123506 invoked by uid 89); 16 Sep 2015 12:28:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Sep 2015 12:28:07 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 16 Sep 2015 05:28:07 -0700 X-ExtLoop1: 1 Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by fmsmga002.fm.intel.com with ESMTP; 16 Sep 2015 05:28:04 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.201]) by IRSMSX108.ger.corp.intel.com ([169.254.11.12]) with mapi id 14.03.0224.002; Wed, 16 Sep 2015 13:27:42 +0100 From: "Metzger, Markus T" To: Eli Zaretskii , Pedro Alves CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH v2 17/17] infrun: scheduler-locking reverse Date: Wed, 16 Sep 2015 12:28:00 -0000 Message-ID: References: <1441954298-25298-1-git-send-email-markus.t.metzger@intel.com> <1441954298-25298-18-git-send-email-markus.t.metzger@intel.com> <83io7h4eze.fsf@gnu.org> <55F2970D.6040603@redhat.com> <838u8d49d3.fsf@gnu.org> In-Reply-To: <838u8d49d3.fsf@gnu.org> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00368.txt.bz2 > -----Original Message----- > From: Eli Zaretskii [mailto:eliz@gnu.org] > Sent: Friday, September 11, 2015 11:02 AM > To: Pedro Alves > Cc: Metzger, Markus T; gdb-patches@sourceware.org > Subject: Re: [PATCH v2 17/17] infrun: scheduler-locking reverse >=20 > > Date: Fri, 11 Sep 2015 09:55:41 +0100 > > From: Pedro Alves > > CC: gdb-patches@sourceware.org The second paragraph of [1] says "When this [record] target is in use, if t= he execution log includes the record for the next instruction, gdb will debug = in replay mode.". Following this definition of "replay mode", I agree with Eli's first sugges= tion to call the new scheduler-locking mode "replay". I'm avoiding the term "replay" since esp. record btrace does not replay in = the sense of "re-execute the program". All it does is move the PC around. Rec= ord full does a bit more but it is still not re-executing the program. > > I'll admit that when reviewing this, I also noticed that the setting > > applies both when stepping backwards, and when replaying forward, > > and wondered whether that would be confusing. > > > > Do we call reverse execution "replay" too? The docs are a bit confusing > > on this, sometimes it looks like we do, sometimes not. E.g., [1] > > > > When debugging in the reverse direction, gdb will work in replay mode= as > > long as the execution log includes the record for the previous instru= ction; > > otherwise, it will work in record mode, if the platform supports reve= rse > > execution, or stop if not. > > > > [1] - https://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and- > Replay.html#Process-Record-and-Replay > > > > I think the "If the platform supports reverse execution" part is talking > > about when the remote target supports reverse debugging directly, > > like e.g., Qemu / Simics / VMWare(?). > > > > But then it seems confusing to call reverse stepping "record mode", > > as in "if it's rewinding time, what it is recording??". It looks like "replay" mode means that GDB is executing from its (own) execution log; "record" mode means that GDB is extending its execution log. Traditionally, GDB records when stepping forward from the end of the execution log. On targets that support native reverse-stepping, however, GDB is able to extend its execution log also when stepping backward from the beginning of GDB's execution log. This doesn't work with record btrace. Regards, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul Chairperson of the Supervisory Board: Tiffany Doon Silva Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928