From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35150 invoked by alias); 16 Sep 2015 13:32:43 -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 35126 invoked by uid 89); 16 Sep 2015 13:32:42 -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; Wed, 16 Sep 2015 13:32:41 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 7DCC91BD093; Wed, 16 Sep 2015 13:32:40 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8GDWcIR005951; Wed, 16 Sep 2015 09:32:39 -0400 Message-ID: <55F96F76.4090108@redhat.com> Date: Wed, 16 Sep 2015 13:32: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: "Metzger, Markus T" , Eli Zaretskii 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> <55F2970D.6040603@redhat.com> <838u8d49d3.fsf@gnu.org> <55F96679.7070503@redhat.com> In-Reply-To: <55F96679.7070503@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-09/txt/msg00374.txt.bz2 On 09/16/2015 01:54 PM, Pedro Alves wrote: > On 09/16/2015 01:27 PM, Metzger, Markus T wrote: >>> -----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 >>> >>>> 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 the >> 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 suggestion >> to call the new scheduler-locking mode "replay". > > Me too. Actually, there's still one detail, that goes back to what I first asked; whether we call reverse execution "replay" too. So it now sounds clearer to me that when we're reverse debugging with a target that does native reverse-stepping, where the user is not using a record/replay target and has not typed "record", etc., we don't call reverse debugging "replay". However, the patch had this: + else if ((scheduler_mode == schedlock_reverse) + && ((execution_direction == EXEC_REVERSE) + || target_record_is_replaying (minus_one_ptid))) + { That means that the setting is in effect also when reverse debugging _without_ a record/replay target, e.g., with qemu/simics/etc. Do we want the setting to take effect with these too, or do we not? It doesn't a difference in practice today because the RSP packets for reverse debugging assuming a single threaded target, but once we support connecting to multiple remote targets at the same time, for instance, it would come into effect. Just bringing this up so we make an informed decision. Thanks, Pedro Alves