From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128777 invoked by alias); 11 Sep 2015 08:55:47 -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 128768 invoked by uid 89); 11 Sep 2015 08:55:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 11 Sep 2015 08:55:46 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id EC12AA2C0A; Fri, 11 Sep 2015 08:55:44 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8B8tgx7014160; Fri, 11 Sep 2015 04:55:42 -0400 Message-ID: <55F2970D.6040603@redhat.com> Date: Fri, 11 Sep 2015 08:55:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eli Zaretskii , Markus Metzger CC: gdb-patches@sourceware.org Subject: Re: [PATCH v2 17/17] infrun: scheduler-locking reverse 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> In-Reply-To: <83io7h4eze.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-09/txt/msg00211.txt.bz2 On 09/11/2015 08:00 AM, Eli Zaretskii wrote: >> From: Markus Metzger >> Cc: gdb-patches@sourceware.org, Eli Zaretskii >> Date: Fri, 11 Sep 2015 08:51:38 +0200 >> >> Record targets behave as if scheduler-locking were on during replay/reverse >> execution. Add a new scheduler-locking option "reverse" to make this implicit >> behaviour explicit. It behaves like "on" during reverse/replay execution and >> like "off" during normal execution. > > I suggest to call this value "replay" instead. "Reverse" has other > meanings that can interfere with its mnemonic value. 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 instruction; otherwise, it will work in record mode, if the platform supports reverse 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??". Thanks, Pedro Alves