From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111093 invoked by alias); 13 Jun 2016 15:21:54 -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 111081 invoked by uid 89); 13 Jun 2016 15:21:52 -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=logs, indication, Hx-languages-length:3026, polishing X-HELO: mga14.intel.com Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Jun 2016 15:21:42 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 13 Jun 2016 08:21:41 -0700 X-ExtLoop1: 1 Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga001.jf.intel.com with ESMTP; 13 Jun 2016 08:21:39 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.117]) by IRSMSX152.ger.corp.intel.com ([169.254.6.247]) with mapi id 14.03.0248.002; Mon, 13 Jun 2016 16:21:39 +0100 From: "Metzger, Markus T" To: Marc Khouzam , "Pedro Alves (palves@redhat.com)" CC: "gdb@sourceware.org" Subject: RE: Stopping reverse debugging behaves differently with btrace Date: Mon, 13 Jun 2016 15:21: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/msg00015.txt.bz2 Hi Marc, Pedro, > > > I find it strange though that when turning off record, every indicati= on > > > to the user is that we are still at line 150, when in reality, GDB is > > > effectively back at line 200. This is particularly noticeable in a > > > frontends when execution jumps (unexpectedly) when the first step > > > is requested. > > > > > > Variables also remain unavailable until the next step (or strangely, > > > until I send some register command). > > > > > > I was wondering if GDB should reset its execution to the proper > > > place upon a 'record stop' for btrace? And notify the frontend of > > > that change. > > > > I agree. I'll look into it. Thanks for pointing it out. >=20 > I have a fix for the missing STOP_PC update which may result in all > kinds of strange effects. The front-end notification sounds more > tricky, though. Looks like the trick is to clear the proceed state of the moving thread before calling the normal-stop observer. I'm omitting the about-to- proceed notification and I'm not calling proceed or normal_stop. I hope I'm not breaking something. GDB is now sending a normal-stop without stop reason on every record goto command: (gdb)=20 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[],f= rom=3D"/lib64/libc.so.6"},thread-id=3D"1",stopped-threads=3D"all",core=3D"1" ^done We can also invent a new stop-reason if necessary. The record-btrace target also sends such a normal-stop notification on "record stop" for each replaying thread: (gdb)=20 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",value=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-th= reads=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",value=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-th= reads=3D"all",core=3D"1" ~"Process record is stopped and all execution logs are deleted.\n" =3Drecord-stopped,thread-group=3D"i1" ^done Marc, is this what you were expecting? The CLI output for "record stop" needs more polishing. It currently prints= the updated source location for every replaying thread without indicating the t= hread the output belongs to. Not sure how much output we really want on the CLI = for "record stop". 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