From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1220 invoked by alias); 13 Jun 2016 17:43:53 -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 1208 invoked by uid 89); 13 Jun 2016 17:43:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=unkown, H*RU:Unknown_Domain, Hx-spam-relays-external:Unknown_Domain, H*r:Unknown_Domain X-HELO: usplmg21.ericsson.net Received: from usplmg21.ericsson.net (HELO usplmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 13 Jun 2016 17:43:45 +0000 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id D2.36.03614.390FE575; Mon, 13 Jun 2016 19:42:44 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0294.000; Mon, 13 Jun 2016 13:43:42 -0400 From: Marc Khouzam To: "Metzger, Markus T" , "Pedro Alves (palves@redhat.com)" CC: "gdb@sourceware.org" Subject: RE: Stopping reverse debugging behaves differently with btrace Date: Mon, 13 Jun 2016 17:43:00 -0000 Message-ID: References: , In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00019.txt.bz2 > Hi Marc, Pedro, > > > > > I find it strange though that when turning off record, every indica= tion > > > > 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. > > > > 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. >=20 > 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. >=20 > GDB is now sending a normal-stop without stop reason on every record > goto command: >=20 > (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"/lib64/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 command=20 changes the line at which GDB is stopped, the frontend needs a *stopped event like that. Sending multiple *stopped events for the same thread with= out a *running event in between may be a new case; I don't know if that is some= thing=20 frontends are supposed to be ready for. I'm almost certain Eclipse can han= dle it though. > We can also invent a new stop-reason if necessary.=20=20 That is probably a nice clarification for the frontend. However, looking at how Eclipse handles the 'reason' field, we are not ready 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 would = make Eclipse accept any unkown reason as a generic *stopped event, but older versions of Eclipse won't have that fix. Please keep me in the loop about such a change. > The record-btrace > target also sends such a normal-stop notification on "record stop" for > each replaying thread: >=20 > (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",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 >=20 > Marc, is this what you were expecting? That also seems right. Eclipse does not yet support reverse debugging with non-stop, but we are working on it. > The CLI output for "record stop" needs more polishing. It currently prin= ts the > updated source location for every replaying thread without indicating the= thread > the output belongs to. Not sure how much output we really want on the CL= I for > "record stop". >=20 > Regards, > Markus. Thanks for looking into this so quickly. Marc