From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25117 invoked by alias); 24 Sep 2003 22:41:39 -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 25109 invoked from network); 24 Sep 2003 22:41:38 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 24 Sep 2003 22:41:38 -0000 Received: by zenia.home (Postfix, from userid 5433) id 4835020766; Wed, 24 Sep 2003 17:38:08 -0500 (EST) To: Saravanan Cc: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: Tracepoint support in Cygnus GDB ? References: <3F717475.33E13BC4@india.hp.com> <6654-Wed24Sep2003201904+0300-eliz@elta.co.il> From: Jim Blandy Date: Wed, 24 Sep 2003 22:41:00 -0000 In-Reply-To: <6654-Wed24Sep2003201904+0300-eliz@elta.co.il> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-09/txt/msg00310.txt.bz2 "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. > > 3. Does tracepoint use the same TRAP (or ILLEGAL ) > > instruction mechanism for tracepoints as it does for > > breakpoints? > > IIRC, yes. Yep.