From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85075 invoked by alias); 7 Jun 2016 20:13:16 -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 85065 invoked by uid 89); 7 Jun 2016 20:13:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy= 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; Tue, 07 Jun 2016 20:13:15 +0000 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id EC.E2.03614.F9A27575; Tue, 7 Jun 2016 22:12:16 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0294.000; Tue, 7 Jun 2016 16:13:12 -0400 From: Marc Khouzam To: "gdb@sourceware.org" Subject: Stopping reverse debugging behaves differently with btrace Date: Tue, 07 Jun 2016 20:13:00 -0000 Message-ID: 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/msg00005.txt.bz2 Hi, I noticed a difference of behaviour when stopping reverse debugging with btrace vs record/replay (full mode). If full mode, if I step to line 200 and then back to line 150 then give the record stop command, real execution will start from line 150 as=20 I step my program. (This is really cool btw.) In btrace mode (I tried bts), after I step back to line 150 and send=20 the record stop command, GDB appears to still be at line 150 but on the next step, execution jumps to line 200 before doing the step=20 operation. I'm guessing this has to do with the fact that btrace does not store=20 registers and memory, so cannot restart execution just anywhere.=20=20 I find it strange though that when turning off record, every indication=20 to the user is that we are still at line 150, when in reality, GDB is=20 effectively back at line 200. This is particularly noticeable in a=20 frontends when execution jumps (unexpectedly) when the first step is requested.=20=20 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. Any opinions? Thanks Marc