From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15885 invoked by alias); 27 Oct 2009 20:10:01 -0000 Received: (qmail 15873 invoked by uid 22791); 27 Oct 2009 20:10:00 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Oct 2009 20:09:55 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 6E6FF13906; Tue, 27 Oct 2009 13:09:52 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost3.vmware.com (Postfix) with ESMTP id 18551CDA4C; Tue, 27 Oct 2009 13:09:52 -0700 (PDT) Message-ID: <4AE751C8.2070902@vmware.com> Date: Tue, 27 Oct 2009 20:15:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Jakob Engblom CC: "gdb@sourceware.org" Subject: Re: gdb-serial: inform gdb that target has changed References: <007101ca573c$0dfd9fa0$29f8dee0$@com> In-Reply-To: <007101ca573c$0dfd9fa0$29f8dee0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2009-10/txt/msg00401.txt.bz2 Jakob Engblom wrote: > Hi! > > While looking over gdb7 and getting our tool to work with it, we realized we > still have an old outstanding issue with gdb-serial and using gdb as a debugger > frontend. It is the fact that gdb assumes that it is in control, and the target > cannot tell gdb to refresh its state since the target has changed outside of > gdb's control. Today we do the work-around of disconnecting and connecting the > connection to force gdb to refresh, which is not particularly elegant. > > Example cases: with reverse execution and a user on the back-end side jumping to > back-end bookmarks in time, or triggering breakpoints on hardware accesses or > other events that gdb have no real idea of. Hi Jakob, I'd like to know more about the context, but my first suggestion is probably going to be the same in any event -- have you tried this command instead of disconnect? (gdb) help flushregs Force gdb to flush its register cache (maintainer command) After this command, if you give "frame", or any other command that causes gdb to need to know where the target is, gdb will fetch the registers afresh. Now as to your context, and my questions... Is this something that is happening when gdb is "at the prompt"? Of course, in normal (sync) mode, gdb assumes that nothing is happening on the target while we sit at the gdb prompt. Just for understanding...