From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24739 invoked by alias); 4 Nov 2008 21:37:21 -0000 Received: (qmail 24701 invoked by uid 22791); 4 Nov 2008 21:37:20 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Nov 2008 21:36:44 +0000 Received: (qmail 27382 invoked from network); 4 Nov 2008 21:36:41 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 Nov 2008 21:36:41 -0000 Message-ID: <4910C062.4040404@codesourcery.com> Date: Tue, 04 Nov 2008 21:37:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Michael Snyder CC: Jakob Engblom , '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> <490F4DDD.3040407@vmware.com> In-Reply-To: <490F4DDD.3040407@vmware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00028.txt.bz2 Michael Snyder wrote: > [...] 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*". Hmm, that is a significant wrinkle to the execution history theory. Basically it's not possible to know reliably whether the execution state of one CPU comes sooner or later than the state of another CPU - their clocks can't be guaranteed to be sync'ed to a sub-instruction level. It's a little like a distributed version control system, where each repository has its own version numbers, and any ordering derives from explicit push/pull instructions. Each inferior can have a reliable execution history, but if you want to go back to state X on CPU 1, you either just affect the one inferior, or expect that other inferiors will go back to the closest available state in their histories. Stan