From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17094 invoked by alias); 1 Mar 2008 19:36:56 -0000 Received: (qmail 17086 invoked by uid 22791); 1 Mar 2008 19:36:56 -0000 X-Spam-Check-By: sourceware.org Received: from Unknown (HELO mail.hofr.at) (194.112.174.227) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Mar 2008 19:36:38 +0000 Date: Sat, 01 Mar 2008 19:36:00 -0000 From: Nicholas Mc Guire To: Lokesh Gupta cc: Michael Snyder , gdb@sourceware.org Subject: Re: Tracepoints functionality for local targets In-Reply-To: <21b011a40802270008u4efb67av598dce53a828913f@mail.gmail.com> Message-ID: References: <21b011a40802260027r596c2c0bt96339538b8e5cc92@mail.gmail.com> <1204051129.19253.305.camel@localhost.localdomain> <21b011a40802270008u4efb67av598dce53a828913f@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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-03/txt/msg00004.txt.bz2 > > Can't we take the following approach to this issue: > > - Treat tracepoints as 'silent' breakpoints such that when the user > sets tracepoints actually a breakpoint is inserted with a special > property called as 'trace-silent' that is what the current implementation actually does except that we put the tracepoint into a seperate list of breakpoint instead of changing the description of the currently in use breakpoints. Basically this was done this way because working your way through the path of the breakpoint code atleast in gdbserver was a complete mess. > - During execution, when this breakpoint is hit, the usual GDB flow of > handling the breakpoint comes into picture, GDB gets control, it > collects all required data from the current frame ($regs,$args,$locals > as requested by user for this tracepoint), and then silently continues > the execution because it can identify it as a special breakpoint with > the property of 'trace-silent' The main difference is that you need to add gdb bytecode to the picture because variables or expressions can't directly be resolved as at time of defining the variable you don't actually have access to the target - that is taken care by translating expressions to bytecode and sending the bytecode to the target that then executes it on hitting a tracepoint and stores the result only. > - The data which is collected by an enabled tracepoint is stored as a > 'snapshot' which is a node in a linked list of all snapshots collected > during program execution. This linked list could be used for the > implementation of the tfind like functions to provide necessary > information to the user. thats just what the current implementation does - see tp.c and list.c in the tracpoint code. hofrat