From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22091 invoked by alias); 3 Nov 2008 18:53:30 -0000 Received: (qmail 22002 invoked by uid 22791); 3 Nov 2008 18:53:30 -0000 X-Spam-Check-By: sourceware.org Received: from vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Nov 2008 18:52:48 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 48C6826EF6F; Mon, 3 Nov 2008 19:52:42 +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 0FD9E26EF65; Mon, 3 Nov 2008 19:52:42 +0100 (CET) From: "Jakob Engblom" To: "'Michael Snyder'" Cc: "'Stan Shebs'" , References: <490B630F.8010008@codesourcery.com> <490B6CEF.2000003@vmware.com> <003e01c93d7e$94eb1de0$bec159a0$@com> <490F40CB.60205@vmware.com> In-Reply-To: <490F40CB.60205@vmware.com> Subject: RE: Tracepoint enhancements Date: Mon, 03 Nov 2008 18:53:00 -0000 Message-ID: <010301c93de5$581d7360$08585a20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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/msg00012.txt.bz2 > > 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. > > The target might have its own interface for looking at such checkpoints... so I > > think passing name strings make the most sense. In Simics, for example, > > bookmarks as we call them have names and that is how we work with them. > > Right -- so for you an internal representation might look like a string. > For VMware, it would look like a pair of integers. If we did an > implementation linux gdbserver, in which gdbserver did the "fork > trick" (like gdb does now), then the internal representation would > be a process ID. > > But for all of these, gdb might keep an external representation > that just looked like a counting integer -- as it does for breakpoints > and threads. That way the user would have a common interface > (eg. "restore 3"), no matter which target. That is a decent idea. > >> Not very different from threads, actually... > > > > I think it is. It is a snapshot of the system state that you can back to, not > > really a thread. Only if you consider the odd Linux implementating with fork et > > al are they the same. > > Sorry, I just meant "like threads in that we have a counting > integer representation on the GDB side, even though there are > various internal representations on the target side". Sorry, misunderstood. Thanks. /jakob