From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6701 invoked by alias); 1 Nov 2008 08:40:45 -0000 Received: (qmail 6631 invoked by uid 22791); 1 Nov 2008 08:40:44 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Nov 2008 08:40:03 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KwC1W-0006Zx-Bl for gdb@sources.redhat.com; Sat, 01 Nov 2008 08:39:58 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Nov 2008 08:39:58 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Nov 2008 08:39:58 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Tracepoint enhancements Date: Sat, 01 Nov 2008 08:40:00 -0000 Message-ID: References: <490B630F.8010008@codesourcery.com> <490B6CEF.2000003@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 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/msg00002.txt.bz2 Michael Snyder 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... I think breakpoints and tracepoints have very lots of common. First of all, the logic of resolving location specification to addresses is, conceptually the same. Right now, breakpoints in constructors and template functions work. Tracepoints don't seem to, because the fail to use the multi-location breakpoint mechanisms. Tracepoints don't have conditions -- which is something we want to fix -- and handling of condition is a bit tricky too. Breakpoints in shared libraries work just fine -- and tracepoints should work too -- but they don't use pending breakpoints mechanisms. On the interface (MI) level breakpoints and tracepoints are essentially the same. Breakpoints allow user, or frontend, to do something at specific points of program. That something very well can be printing variables. In fact, KDevelop does have "tracing" functionality for breakpoints -- where on breakpoint hit, selected variables are printed and execution resumes. Tracepoints are exactly the same, except that: - they are more efficient - they don't cause frontend to be involved, because to be efficient, they are entirely stub-side So it makes perfect sense to treat tracepoints as specially-optimized versions of breakpoints. In order for breakpoint to be optimized like this, the list of commands for that breakpoints should only use a limited set of commands, and end with 'continue' > One more thing, only vaguely related... > > I've thought that if we had the ability to attach an expression > (in pcode such as we use for tracepoints) to a conditional breakpoint, > we could have the conditional evaluation be done on the target > rather than by gdb, which would be a big performance win for > conditional breakpoints or watchpoints. Yes. We want conditional tracepoints, and the condition would have to be evaluated on the target. And if breakpoints and tracepoints are unified, both breakpoints and tracepoints will benefit. - Volodya