From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6770 invoked by alias); 1 Jan 2004 21:33:06 -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 6752 invoked from network); 1 Jan 2004 21:33:04 -0000 Received: from unknown (HELO calvin.codito.com) (203.199.140.162) by sources.redhat.com with SMTP; 1 Jan 2004 21:33:04 -0000 Received: from codito.com (numenor.codito.co.in [192.168.100.52]) by calvin.codito.com (8.12.10/) with ESMTP id i01LUU1B011269; Fri, 2 Jan 2004 03:00:31 +0530 Message-ID: <3FF49153.50100@codito.com> Date: Thu, 01 Jan 2004 21:33:00 -0000 From: Ramana Radhakrishnan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 MIME-Version: 1.0 To: Daniel Jacobowitz , Andrew Cagney , gdb@sources.redhat.com, ankit thukral Subject: [RFC] Addition of remote tracepoints to gdb / gdbserver. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00012.txt.bz2 Hi All , This is a proposal to add support for tracepoints for remote debugging to gdb / gdbserver. Over the next couple of weeks I will submit patches to take care of the same. The source for these patches is based on work done by Ankit Thukral in an internal project with gdb here at Codito Technologies .This mail is an attempt to summarize the discussions had on the mailing list so far regarding the same. Tracepoints require the debuggee to run without being interrupted since the latency caused by it may defer the behaviour of the debuggee.Tracepoints are put at various points in the debuggee and actions are defined for : 1. collecting registers 2. collecting memory regions. 3. evaluating an agent expression and storing the result. The debuggee stops to collect the data,but that is transparent to the user. The other changes that we propose to make to gdbserver include : * Making gdbserver itself multi-threaded and able to communicate with gdb and continue to debug the inferior. This would necessitate a version of libpthread for the target which anyways would be a transitive dependency (gdbserver -> libpthread_db ->libpthread) . * Agent Expression Interpreter for gdbserver. files modified / to be modified (added / to be added) (directory gdbserver): 1. remote-tracepoint.c : Routines to take care of tracepoint data structures / storage. 2. remote-tracepoint.h : Corresponding header files. 3. server.c : Changes to allow gdbserver to be asynch. 4. regcache.c 5. inferiors.c 6.. tracepoint.c (GDB directory). Mechanism : We use the same mechanism as is used for breakpoints, the difference being in the actions being performed at the corresponding tracepoints. Collecting data at any tracepoint would stop if a. any one of the tracepoints has been hit it's respective PASSCOUNT number of times. b. the user types TSTOP (from the GDB). c. the debuggee process finishes. To have support for making the trace experiment stop whenever the user asks for it (using TSTOP),a thread was spawned for the same purpose.this thread would just wait for TSTOP (and reply to any no. of TSTATUS queries) and return. Problems Faced: 1. Though the GDB expects the stub to support agent expressions,it never picks up the corresponding data from the GDBSERVER.for instance, for a request like : collect VAR1 + VAR2 It generates some 30 odd bytes of agent expression and sends it to the GDBSERVER.but at the time of tdump,GDB sends 2 memory requests, one for each of them,adds them and shows the result. One more thing about it is that it doesn't work for floating point variables on the GDB side since there is no floating point support in the AX-Interpreter. 2. There are 3 ways of collecting Transparent memory regions : A. Read the data from the executable using the BFD (as suggested by Jim Blandy on the mailing list).But right now GDBSERVER doesn't have a BFD so he's not sure how to get around this problem. B. Store all the transparent regions transmitted by GDB and read from memory when GDB requests them.but for this,it is imperative that the debuggee process doesn't exit.Hence we make the debuggee stop before it actually finishes up . C. Restart the debuggee (in case it has exited).The aforesaid memory regions are available. Right now,we follow approach (B) of not storing the addresses of Transparent regions transmitted by GDB but am treating them as any normal memory request.This requires a change in the QTro packet sent by the GDB, the additional information being an internal breakpoint at an address as the first thing following the "QTro".Right now,the internal breakpoint is on _FINI(). cheers Ramana --- Ramana Radhakrishnan GNU Tools Codito Technologies Pune - India