From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23222 invoked by alias); 16 Sep 2015 13:56:42 -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 23210 invoked by uid 89); 16 Sep 2015 13:56:41 -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: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Sep 2015 13:56:40 +0000 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP; 16 Sep 2015 06:56:39 -0700 X-ExtLoop1: 1 Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga003.jf.intel.com with ESMTP; 16 Sep 2015 06:56:37 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.201]) by IRSMSX107.ger.corp.intel.com ([169.254.10.97]) with mapi id 14.03.0224.002; Wed, 16 Sep 2015 14:56:35 +0100 From: "Metzger, Markus T" To: Pedro Alves , Eli Zaretskii CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH v2 17/17] infrun: scheduler-locking reverse Date: Wed, 16 Sep 2015 13:56: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> <55F96679.7070503@redhat.com> <55F96F76.4090108@redhat.com> In-Reply-To: <55F96F76.4090108@redhat.com> 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/msg00376.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Wednesday, September 16, 2015 3:33 PM > To: Metzger, Markus T; Eli Zaretskii > Cc: gdb-patches@sourceware.org > Subject: Re: [PATCH v2 17/17] infrun: scheduler-locking reverse > 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: >=20 > + else if ((scheduler_mode =3D=3D schedlock_reverse) > + && ((execution_direction =3D=3D EXEC_REVERSE) > + || target_record_is_replaying (minus_one_ptid))) > + { The target_record_is_replaying (minus_one_ptid) call checks whether a) there is a record target and b) whether at least one thread is in replay mode. We might have a record target but none of the threads are currently replaying. For record btrace this means that all threads are at the end of their execution history (including an empty history). That's why we need to check the execution direction, as well. > 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. What if we added an execution_direction parameter to to_record_is_replaying? I wouldn't use the global variable since it isn't obvious that the execution mode plays any role here. It might further change between the check and the actual resume. Record btrace would return true if at least one thread is replaying or if the execution direction is reverse. Record full would return true if either a) the execution direction is reverse and at least one thread is not at the beginning of its execution history. b) the execution direction is forward and at least one thread is not at the end of its execution history. That is, it will, once it actually supports this. The default would be false. If you're OK with this, I can add it as a separate patch and use it in the schedlock patch. 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