From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5481 invoked by alias); 4 Nov 2008 21:58:31 -0000 Received: (qmail 5454 invoked by uid 22791); 4 Nov 2008 21:58:30 -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; Tue, 04 Nov 2008 21:57:54 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 0263C13438; Tue, 4 Nov 2008 13:57:49 -0800 (PST) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost5.vmware.com (Postfix) with ESMTP id E9827DC073; Tue, 4 Nov 2008 13:57:48 -0800 (PST) Message-ID: <4910C3B3.1070807@vmware.com> Date: Tue, 04 Nov 2008 21:58:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Stan Shebs CC: Jakob Engblom , "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> <4910C062.4040404@codesourcery.com> In-Reply-To: <4910C062.4040404@codesourcery.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/msg00029.txt.bz2 Stan Shebs wrote: > 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. All true. I think this sub-branch of the discussion was mostly blue-sky.