[RFC] Addition of remote tracepoints to gdb / gdbserver.

[Ramana Radhakrishnan <ramana dot radhakrishnan at codito dot com>]

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