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

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jan 02, 2004 at 02:59:55AM +0530, Ramana Radhakrishnan wrote:
> 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) .

Ew.  No.  There is no reason that communicating with GDB while
debugging requires a multi-threaded debug agent; non-blocking I/O is
quite adequate.

It may be easier to prototype this sort of thing using multiple
threads, but the overhead of using libpthread in the debug agent is
just not acceptable.  This will probably require a small finite state
machine, or better use of SIGCHLD.

> * Agent Expression Interpreter for gdbserver.

Yes, certainly.

> 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.

Does the debuggee stop after tstop, or just trace collection stop?  I'm
guessing the latter but the GDB manual is not clear.

> 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.

Hmm, that's odd.  It should probaby just collect VAR1 and VAR2 in that
case.  Does the generated agent expression compute the sum, or does it
compute the location of those variables?

>      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.

Hmm, this will require extending the AX language, as described in the
manual.  Do we need anything other than to treat them as
byte-sequences, though?  Theoretically you might want agent expressions
which did something like *(int *)(int)(double) $f0, but in practice I
doubt that is useful.

> 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().

There are better ways to do this on modern kernels.  We should make
gdbserver support that.  I can do it later.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer