From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29805 invoked by alias); 5 Nov 2008 09:04:25 -0000 Received: (qmail 29722 invoked by uid 22791); 5 Nov 2008 09:04:24 -0000 X-Spam-Check-By: sourceware.org Received: from oden.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Nov 2008 09:03:30 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id E2EB026EEE8; Wed, 5 Nov 2008 10:03:25 +0100 (CET) Received: from polhem (c83-253-20-211.bredband.comhem.se [83.253.20.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id B049626EEDD; Wed, 5 Nov 2008 10:03:25 +0100 (CET) From: "Jakob Engblom" To: "'Stan Shebs'" , "'Michael Snyder'" Cc: 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> Subject: RE: Tracepoint enhancements Date: Wed, 05 Nov 2008 09:04:00 -0000 Message-ID: <002601c93f25$5aeaffe0$10c0ffa0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: sv 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/msg00034.txt.bz2 > > [...] 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. This is true on most physical hardware, but it can often be worked around in simulators. So I would strongly suggest letting the backend worry about tha= t. In a system such as Simics and other complete simulation solutions, this is indeed feasible since you impose a certain semantics on the execution of the simulated system.=20 Or imagine connecting to a cycle-by-cycle simulation or emulation solution = such as a HAPS or Palladium or ZeBu system -- such solutions can stop synchronou= sly on a single cycle. Also, on-chip trace is coming out that would be able to = do synchronized time-stamping of event from an entire SoC, exported over some hardware debug port.=20 So while not always true, there are several cases where you can indeed have= a synchronized history and control over parallellism. All you need is to inse= rt a layer of indirection that converts parallel to some kind of known sequential execution. Best regards, /jakob _______________________________________________________ Jakob Engblom, PhD, Technical Marketing Manager Virtutech Direct: +46 8 690 07 47=20=20=20=20 Drottningholmsv=E4gen 14 Mobile: +46 709 242 646=20=20=20 11243 Stockholm Web: www.virtutech.com=20=20 Sweden ________________________________________________________ =20