From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111305 invoked by alias); 9 Jun 2016 14:11:11 -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 111295 invoked by uid 89); 9 Jun 2016 14:11:10 -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=notifications, commercial, Tel, tel 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; Thu, 09 Jun 2016 14:11:00 +0000 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 09 Jun 2016 07:10:58 -0700 X-ExtLoop1: 1 Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by orsmga003.jf.intel.com with ESMTP; 09 Jun 2016 07:10:57 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.117]) by irsmsx110.ger.corp.intel.com ([163.33.3.25]) with mapi id 14.03.0248.002; Thu, 9 Jun 2016 15:08:54 +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: Thu, 09 Jun 2016 14:11: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/msg00007.txt.bz2 Hi Marc, Pedro, > > I find it strange though that when turning off record, every indication > > 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. >=20 > 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. If I understand the code correctly, infrun's normal_stop calls a normal_stop observer to which front-ends register. The front-end is then responsible for printing the current source location. In the case of MI, this should a= lso give the stopped notification to GUIs. I assume it's this notification you= 're talking about. We also shouldn't get a notification for the "record goto" command. This affects all record targets. Historically, the "record goto" command does n= ot call the normal_stop observer and instead calls print_stack_frame directly. Are= you seeing this, as well, Marc? When I try to either call observer_notify_normal_stop (NULL, 1) directly or indirectly via normal_stop, I get repeated breakpoint notifications for the breakpoint at which the thread stopped originally. Looking at those functi= ons I may get other notifications, as well, depending on global state. It looks like the trick is to do what's normally done after target_wait. I= found some code in infrun that seems to do something like that: /* Go through handle_inferior_event/normal_stop, so we always have consistent output as if the stop event had been reported. */ ecs->ptid =3D info->ptid; ecs->event_thread =3D info; ecs->ws.kind =3D TARGET_WAITKIND_STOPPED; ecs->ws.value.sig =3D GDB_SIGNAL_0; handle_inferior_event (ecs); if (!ecs->wait_some_more) { /* Cancel any running execution command. */ thread_cancel_execution_command (info); normal_stop (); } When I do that for "record goto" and "record stop" I get "Thread x stopped.= " as well as "Switching to thread x" notifications. I'm not sure if we want the= m. Pedro, is this the right direction? Would we need to go through the entire proceed/resume/wait flow? Or is the above already too complicated? Thanks, 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