From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61543 invoked by alias); 14 Jun 2016 07:40:33 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 61528 invoked by uid 89); 14 Jun 2016 07:40:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=contrary, unkown, *stopped, *running 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; Tue, 14 Jun 2016 07:40:22 +0000 Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP; 14 Jun 2016 00:40:20 -0700 X-ExtLoop1: 1 Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga004.fm.intel.com with ESMTP; 14 Jun 2016 00:40:20 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.117]) by IRSMSX154.ger.corp.intel.com ([169.254.12.28]) with mapi id 14.03.0248.002; Tue, 14 Jun 2016 08:40:18 +0100 From: "Metzger, Markus T" To: Marc Khouzam CC: "gdb@sourceware.org" , "Pedro Alves (palves@redhat.com)" Subject: RE: Stopping reverse debugging behaves differently with btrace Date: Tue, 14 Jun 2016 07:40:00 -0000 Message-ID: References: , In-Reply-To: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00023.txt.bz2 Hi Marc, > > GDB is now sending a normal-stop without stop reason on every record > > goto command: > > > > (gdb) > > rec go 12 > > &"rec go 12\n" > > ~"0x00007ffff762c671 in _dl_addr () from /lib64/libc.so.6\n" > > > *stopped,frame=3D{addr=3D"0x00007ffff762c671",func=3D"_dl_addr",args=3D[]= ,from=3D"/li > b64/libc.so.6"},thread-id=3D"1",stopped-threads=3D"all",core=3D"1" > > ^done >=20 > I'd have to try it to be sure, but this looks right. If a record command > changes the line at which GDB is stopped, the frontend needs a *stopped > event like that. Sending multiple *stopped events for the same thread wi= thout > a *running event in between may be a new case; I don't know if that is > something > frontends are supposed to be ready for. I'm almost certain Eclipse can h= andle > it though. Hmmm, the alternative would be to go through the full proceed/resume/ wait/normal_stop flow for "record goto". This would give a ^running and a prompt followed by a *stopped notification. There's a problem with this, though - see below. > > We can also invent a new stop-reason if necessary. >=20 > That is probably a nice clarification for the frontend. > However, looking at how Eclipse handles the 'reason' field, we are not re= ady > for a new one and will ignore any message with an unexpected 'reason'. > Again, I'd have to try it to be sure. It would be easy to fix and I woul= d make > Eclipse accept any unkown reason as a generic *stopped event, but older > versions of Eclipse won't have that fix. OK, let's go without a stop reason for now. > > The record-btrace > > target also sends such a normal-stop notification on "record stop" for > > each replaying thread: > > > > (gdb) > > rec stop > > &"rec stop\n" > > ~"test (arg=3D0x0) at gdb.btrace/multi-thread-step.c:34\n" > > ~"34\t global =3D 42; /* bp.2 */\n" > > > *stopped,frame=3D{addr=3D"0x000000000040078a",func=3D"test",args=3D[{name= =3D"arg",v > alue=3D"0x0"}],file=3D"gdb.btrace/multi-thread-step.c",fullname=3D"gdb.bt= race/multi- > thread-step.c",line=3D"34"},thread-id=3D"1",stopped-threads=3D"all",core= =3D"1" > > ~"test (arg=3D0x0) at gdb.btrace/multi-thread-step.c:34\n" > > ~"34\t global =3D 42; /* bp.2 */\n" > > > *stopped,frame=3D{addr=3D"0x000000000040078a",func=3D"test",args=3D[{name= =3D"arg",v > alue=3D"0x0"}],file=3D"gdb.btrace/multi-thread-step.c",fullname=3D"gdb.bt= race/multi- > thread-step.c",line=3D"34"},thread-id=3D"2",stopped-threads=3D"all",core= =3D"1" > > ~"Process record is stopped and all execution logs are deleted.\n" > > =3Drecord-stopped,thread-group=3D"i1" > > ^done >=20 > That also seems right. > Eclipse does not yet support reverse debugging with non-stop, but we are > working on it. That's the output for stop-all. On "record stop" GDB is iterating over all= threads to stop recording and I'm sending a notification for every thread that moved d= ue to this. If we wanted a stepping-like behavior (as sketched above), GDB would report= a single event in stop-all mode and queue events of other threads to be repor= ted when they are resumed the next time. That's not desirable since we would need multiple "continue" after "record = stop" to drain all those implicit record goto stopped events. To the contrary, GDB implicitly stops replaying other threads if the select= ed thread is resumed at the end of its execution history. This is to avoid having to= switch to all replaying threads and do an explicit "record goto end". Those implicit moves also do not trigger *stopped notifications. I don't t= hink they should. We're getting ^running *running,thread-id=3D"all" which already indicates that other threads may have moved, as well. If we look at another command that affects multiple threads (gdb)=20 kill &"kill\n" =3Dthread-exited,id=3D"1",group-id=3D"i1" =3Dthread-exited,id=3D"2",group-id=3D"i1" =3Dthread-group-exited,id=3D"i1" ^done I think that's what we'd want for "record stop" as well. If *stopped doesn= 't work, we may need a new record. 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, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928