From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20564 invoked by alias); 30 Sep 2003 12:13:31 -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 20555 invoked from network); 30 Sep 2003 12:13:28 -0000 Received: from unknown (HELO calvin.codito.com) (203.199.140.162) by sources.redhat.com with SMTP; 30 Sep 2003 12:13:28 -0000 Received: from numenor.codito.co.in (numenor.codito.co.in [192.168.100.52]) by calvin.codito.com (8.12.8/8.12.5) with ESMTP id h8UCBt4O009882; Tue, 30 Sep 2003 17:41:55 +0530 Subject: Tracepoints on gdb/gdbserver From: Ramana Radhakrishnan Reply-To: ramana@codito.com To: gdb@sources.redhat.com Cc: jimb@redhat.com, ac131313@redhat.com, drow@mvista.com Content-Type: text/plain Organization: Codito Technologies Message-Id: <1064924214.3808.157.camel@numenor.codito.co.in> Mime-Version: 1.0 Date: Tue, 30 Sep 2003 12:50:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00387.txt.bz2 hi all, This is regarding tracepoints on gdb/ gdbserver. What we are 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. * 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. regards Ramana Radhakrishnan