From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32645 invoked by alias); 30 Sep 2003 12:50:24 -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 32636 invoked from network); 30 Sep 2003 12:50:23 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 30 Sep 2003 12:50:23 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A4JxK-00066E-Ai; Tue, 30 Sep 2003 08:50:18 -0400 Date: Tue, 30 Sep 2003 13:06:00 -0000 From: Daniel Jacobowitz To: ramana@codito.com Cc: gdb@sources.redhat.com, jimb@redhat.com, ac131313@redhat.com Subject: Re: Tracepoints on gdb/gdbserver Message-ID: <20030930125017.GA23342@nevyn.them.org> Mail-Followup-To: ramana@codito.com, gdb@sources.redhat.com, jimb@redhat.com, ac131313@redhat.com References: <1064924214.3808.157.camel@numenor.codito.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1064924214.3808.157.camel@numenor.codito.co.in> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00388.txt.bz2 On Tue, Sep 30, 2003 at 05:46:54PM +0530, Ramana Radhakrishnan wrote: > hi all, > This is regarding tracepoints on gdb/ gdbserver. What we are Great! > trying to do is to implement tracepoints in gdbserver so that we could > have some sort of remote tracepointing. We are at a stage right now > where we are ready to take the plunge into actually implementing > tracepoints on gdbserver. What we have ready right now are just stubs > that take care of the protocol communication between gdb/tracepoint.c > and gdbserver/server.c . The following is a list of ideas / issues that > we have come up with. > > > * We were thinking of piggybacking the tracepoint support with > breakpoints in gdbserver , add a flag indicating that it would be a > tracepoint to reuse the code that the software breakpoint now uses in > gdbserver. As we see it there is not too much of a difference between > tracepoints and breakpoints other than the actions performed on a > {break/trace}point hit. By doing this the tracepoint implementation > could piggy back on the breakpoint support and this could also give rise > to per thread tracepoints in a mechanism similar to per thread > breakpoints. That'll work. I got the impression that tracepoints are designed to be even lighter-weight than that; you can implement them via an agent expression -> native assembly conversion. But this requires runtime patching and is quite complicated. Just saving the overhead of the remote protocol will be useful. > * Another specification according to the info pages seems to be that > about the fact that all queries to the stub regarding memory / register > information should be answered by the stub from the current snapshot of > a tracepoint. > > * Changes to be made in memory request handler , the handler for the > m
, packet in gdbserver/server.c to take care of > memory requests of transparent regions. > > * Agent Expressions Interpreter integration with gdbserver. The > interpreter to take care of actions to be performed / the actual data to > be collected for every tracepoint. > > * Collect Locals issue : with gdb snapshot dated 20030821 we are unable > to take care of collect $locals and collect $args .This gives an error > in gdb "Dont know how to trace local symbol ". This seems to be the > error value and it looks like support for the Address Class of a symbol > (LOC_COMPUTED) is not being taken care of right now. That's right. If someone implements the remainder of tracepoint support I'll go back to looking at LOC_COMPUTED. Do you have FSF copyright paperwork on file? If not, please do so. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer