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

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

Daniel Jacobowitz wrote:

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

> > * 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.
>  
The assumption on our side is that the trace experiment stops and hence 
only the trace collection stops. The debuggee continues on its merry 
fashion .

>  
>
> > 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?
>
>  
The generated Agent expression would compute the sum .
The code generated would look something like what is given in the gdb 
manual . This is in contradiction
with what is given in the gdb manual . The manual seems to say that 
given a general expression x+y*z the
code generated is (and i quote )


> >     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.
>  
Now the remote side would have to understand the target floating point 
format / collect the values for
the same and hence the actual computation would have to be target 
specific .2 options
a. do all calculations in gdbserver
b. collect all byte sequences and take care of it in gdb.

Option b seems less expensive.

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


That'd be PTRACE_EXIT_EVENT in the modern kernels.?Something that I 
missed out in my earlier mails.

cheers
Ramana

--
Ramana Radhakrishnan
GNU Tools
Codito Technologies.