From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9802 invoked by alias); 31 Oct 2008 19:57:46 -0000 Received: (qmail 9787 invoked by uid 22791); 31 Oct 2008 19:57:45 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 31 Oct 2008 19:57:10 +0000 Received: (qmail 9997 invoked from network); 31 Oct 2008 19:57:09 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Oct 2008 19:57:09 -0000 Message-ID: <490B630F.8010008@codesourcery.com> Date: Fri, 31 Oct 2008 20:46:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Tracepoint enhancements Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-10/txt/msg00144.txt.bz2 There is some interest in pumping up GDB's tracepoint capabilities, in particular to make it more suitable for cross-debugging a target with serious performance constraints. While a lot of the detail is centered around making a faster stub and other low-level tweaks, we are going to do MI for tracing finally, plus it's an opportunity to review the existing trace commands and consider what interface changes are desirable. In particular, we will want to think about how tracing should interoperate with non-stop debugging and multi-process. So the first question that comes to my mind is: how many people are actually using the trace commands right now? If they're not being much used, then we have more flexibility about making user-visible changes. 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. 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. What else should we be thinking about doing? (There are of course all kinds of implementation-level changes to make, but at the moment I'm focussed on the user experience.) Stan