From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3717 invoked by alias); 25 Sep 2003 04:02:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3694 invoked from network); 25 Sep 2003 04:02:18 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 25 Sep 2003 04:02:18 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A2NKR-0005Y2-6y; Thu, 25 Sep 2003 00:02:07 -0400 Date: Thu, 25 Sep 2003 04:02:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Saravanan , Eli Zaretskii , gdb@sources.redhat.com Subject: Re: Tracepoint support in Cygnus GDB ? Message-ID: <20030925040205.GA21265@nevyn.them.org> Mail-Followup-To: Jim Blandy , Saravanan , Eli Zaretskii , gdb@sources.redhat.com References: <3F717475.33E13BC4@india.hp.com> <6654-Wed24Sep2003201904+0300-eliz@elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00313.txt.bz2 On Wed, Sep 24, 2003 at 05:38:08PM -0500, Jim Blandy wrote: > > "Eli Zaretskii" writes: > > > Date: Wed, 24 Sep 2003 16:09:49 +0530 > > > From: Saravanan > > > > > > 1. Why does GDB not provide this support for local > > > host ? > > > > Simple: because no one wrote tracepoints support for native > > debugging. > > Right -- please contribute support for native tracepoints! > > > > 2. Is it not the case that the features (supposed to > > > be) provided by tracepoints can be done using > > > breakpoint features only (for instance , we can > > > specify COMMANDS for a breakpoint just as we can > > > specify ACTIONS for tracepoints) ? > > > > Yes. But tracepoints are supposed to be much more lightweight > > (because only raw data is accumulated during the program's run, while > > complicated and expensive computations like evaluation of arbitrary > > expressions, are left for later). So, theoretically, if tracepoints > > were available for native debugging, one could perhaps debug programs > > without disrupting their time scale too much, maybe even debug > > real-time programs (well, one's allowed to dream once in a while, > > right? ;-). > > Actually, the tracepoint system *does* evaluate arbitrary expressions > each time a tracepoint is hit. The expressions are compiled to a > bytecode which is pretty simple to interpret. Here's why it's > lightweight: > - The bytecode has had all the symbolic work squeezed out of it --- > it's just a bunch of pretty standard machine-level operations on > machine words. No name lookups, no type checking, etc. So it can > run in much less memory and much less time than GDB's evaluator. > - This means that it can be evaluated entirely on the target. No > communication with the host is needed. You can do a lot of > computation in the time it takes a byte to go across a serial line. > > There are a bunch of ways we could support this on a native system: > > - We could implement it as an extension to ordinary breakpoints: > hitting a tracepoint would stop the inferior; GDB would collect the > data, and then continue the inferior. I think this might not be so > lightweight. > > - We could implement a tracing agent that would actually live in the > inferior and catch some sort of trap. This would be more complex, > but it would disturb the inferior less. Or do it via dynamic code replacement at the start of functions. That's even lighter, though a bit hard to get right. I hope to work on this - some day. Gotta get through dwarf improvements first :) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer