From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18724 invoked by alias); 3 Nov 2008 06:38:24 -0000 Received: (qmail 18688 invoked by uid 22791); 3 Nov 2008 06:38:22 -0000 X-Spam-Check-By: sourceware.org Received: from dns.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Nov 2008 06:37:14 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id A232E26EF40; Mon, 3 Nov 2008 07:37:05 +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 8083326EF39; Mon, 3 Nov 2008 07:37:05 +0100 (CET) From: "Jakob Engblom" To: "'Michael Snyder'" , "'Stan Shebs'" Cc: References: <490B630F.8010008@codesourcery.com> <490B6CEF.2000003@vmware.com> In-Reply-To: <490B6CEF.2000003@vmware.com> Subject: RE: Tracepoint enhancements Date: Mon, 03 Nov 2008 06:38:00 -0000 Message-ID: <003e01c93d7e$94eb1de0$bec159a0$@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/msg00008.txt.bz2 > > 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. >=20 > Just my personal opinion, I would find that confusing. >=20 > 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. >=20 > 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 memo= ry position. Whether you then note it down and continue or stop execution or c= all some callback does not matter. So they can be very much the same.=20 =20 > > 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. >=20 > That could be interesting to talk about. >=20 > 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. >=20 > 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 prog= ram" this is also a nice fit with simulators (and I presume VmWare as well, if w= e use its snapshotting ability for this). I think this is a very good idea that = works very well with a smart remote target.=20 =20 > 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. >=20 > 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. > Not very different from threads, actually... I think it is. It is a snapshot of the system state that you can back to, n= ot really a thread. Only if you consider the odd Linux implementating with for= k et al are they the same. =20 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