From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29878 invoked by alias); 3 Nov 2008 18:27:27 -0000 Received: (qmail 29858 invoked by uid 22791); 3 Nov 2008 18:27:26 -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 18:26:50 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id EB1EE4A002; Mon, 3 Nov 2008 10:26:47 -0800 (PST) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost3.vmware.com (Postfix) with ESMTP id E93BAC9A10; Mon, 3 Nov 2008 10:26:47 -0800 (PST) Message-ID: <490F40CB.60205@vmware.com> Date: Mon, 03 Nov 2008 18:27: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> In-Reply-To: <003e01c93d7e$94eb1de0$bec159a0$@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/msg00011.txt.bz2 Jakob Engblom wrote: >>> One possible change to consider is to merge tracepoint setting into >>> breakpoint setting. Among other benefits would be a single numbering >>> scheme for breakpoints and tracepoints, plus we will be able to share >>> some machinery and make things more consistent. >> Just my personal opinion, I would find that confusing. >> >> It seems useful to maintain a fairly sharp distinction >> between breakpoints and tracepoints, since their behavior >> is entirely different from both the implementation and the >> user's point of view. >> >> But I would not plan to make a fuss about it... > > In a simulator, they might be the same. In both cases, the main mechanism is > noting that you reach a certain place in the code or read or write som memory > position. Whether you then note it down and continue or stop execution or call > some callback does not matter. So they can be very much the same. > >>> A bigger change would be to introduce a general notion of execution >>> history, which could subsume fork checkpoints and trace snapshots, maybe >>> tie into some versions of reverse debugging as well. >> That could be interesting to talk about. >> >> Right now, I think checkpoints are only implemented for native >> linux, and maybe a few other (native) targets. Whereas tracepoints >> are traditionally associated with remote targets. >> >> I am very interested in defining a remote protocol that could >> tell the remote target "take a checkpoint" or "restore to a >> checkpoint". Ideally it should be entirely agnostic about how >> a checkpoint is actually implemented. > > 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. Something corresponding to a snapshot or bookmark. >> I talked about this with somebody once (can't remember who), >> but I remember the discussion got hung up over whether gdb or >> the target should actually manage the list of checkpoint IDs. >> >> My thinking is that gdb will probably want to number them with >> simple ordinal numbers (1, 2, 3...) like breakpoints, but that >> the target may have a different type of ID in mind (such as >> process/fork IDs), and somebody will have to maintain a mapping. > > 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. >> 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".