From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37837 invoked by alias); 17 Jun 2016 11:48:09 -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 37825 invoked by uid 89); 17 Jun 2016 11:48:08 -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=commercial, Tel, tel, office X-HELO: mga11.intel.com Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Jun 2016 11:47:52 +0000 Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP; 17 Jun 2016 04:47:52 -0700 X-ExtLoop1: 1 Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga004.fm.intel.com with ESMTP; 17 Jun 2016 04:47:50 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.117]) by IRSMSX107.ger.corp.intel.com ([169.254.10.96]) with mapi id 14.03.0248.002; Fri, 17 Jun 2016 12:47:49 +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: Fri, 17 Jun 2016 11:48: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/msg00029.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 > > > > I'd have to try it to be sure, but this looks right. If a record comma= nd > > changes the line at which GDB is stopped, the frontend needs a *stopped > > event like that. Sending multiple *stopped events for the same thread = without > > 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= handle > > it though. Eclipse Mars.2 seems to be OK with it. > > > 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.btrace/multi- > > thread-step.c",line=3D"34"},thread-id=3D"1",stopped-threads=3D"all",cor= e=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.btrace/multi- > > thread-step.c",line=3D"34"},thread-id=3D"2",stopped-threads=3D"all",cor= e=3D"1" > > > ~"Process record is stopped and all execution logs are deleted.\n" > > > =3Drecord-stopped,thread-group=3D"i1" > > > ^done > > > > That also seems right. > > Eclipse does not yet support reverse debugging with non-stop, but we are > > working on it. >=20 > That's the output for stop-all. On "record stop" GDB is iterating over a= ll threads to > stop recording and I'm sending a notification for every thread that moved= due to > this. Eclipse seems to be able to handle it but it may cause a thread switch. Pl= us this causes lots of output on the CLI. I don't think we want that. For stop-all mode, I changed this to send a single *stopped for the selecte= d thread - provided it is replaying. This works fine as long as the selected thread a= ctually is replaying. All threads are updated and we're not switching away from the s= elected thread. If the selected thread isn't replaying, however, GDB won't send a *stopped.= This is OK for the selected thread as its state didn't change, but it won't cause o= ther threads that had been replaying to be updated. I added another *stopped event without thread information for that case. E= clipse seems to be OK with it. We're not switching threads but other threads seem= to be updated correctly. I pushed the series into users/mmetzger/record-goto-mi. Let me know what y= ou think and if this is working for you. I will send the patches out for review in = a week or two. 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