From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19543 invoked by alias); 3 Nov 2008 19:23:13 -0000 Received: (qmail 19482 invoked by uid 22791); 3 Nov 2008 19:23:12 -0000 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.31) with ESMTP; Mon, 03 Nov 2008 19:22:36 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id C50E61302F; Mon, 3 Nov 2008 11:22:33 -0800 (PST) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost4.vmware.com (Postfix) with ESMTP id BF99FC9A34; Mon, 3 Nov 2008 11:22:33 -0800 (PST) Message-ID: <490F4DDD.3040407@vmware.com> Date: Mon, 03 Nov 2008 19:23:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Jakob Engblom CC: 'Stan Shebs' , "gdb@sourceware.org" Subject: Re: Tracepoint enhancements References: <490B630F.8010008@codesourcery.com> <490B6CEF.2000003@vmware.com> <003e01c93d7e$94eb1de0$bec159a0$@com> <490F40CB.60205@vmware.com> <010301c93de5$581d7360$08585a20$@com> In-Reply-To: <010301c93de5$581d7360$08585a20$@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: 2008-11/txt/msg00015.txt.bz2 Jakob Engblom wrote: >>> If by checkpoint you mean "some point inside the execution of a single > program" >>> this is also a nice fit with simulators (and I presume VmWare as well, if we >> use >>> its snapshotting ability for this). I think this is a very good idea that >> works >>> very well with a smart remote target. >> Yes, that's what I meant. A "point in time" in the execution >> history, something that could be represented eg. by a cycle count >> or instruction count, rather than just by a PC. > > I think that is a bad idea to assume there is only one time or one instruction > count in the target. It could be a multicore target with lots of CPUs running > around... so let the backend handle that in a symbolic way rather than assume > anything about what it means. Right, OK. But it was a mental assumption rather than an implementation assumption. I think the idea we're both getting at is that a checkpoint represents a machine state. If there are multiple machines, that complicates the picture -- but basically gdb is saying to the target "I want to be able to return to the state that you are in *right now*".