Re: Tracepoint support in Cygnus GDB ?

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Sep 24, 2003 at 05:38:08PM -0500, Jim Blandy wrote:
> 
> "Eli Zaretskii" <eliz@elta.co.il> writes:
> > > Date: Wed, 24 Sep 2003 16:09:49 +0530
> > > From: Saravanan <pes@india.hp.com>
> > >   
> > >   1. Why does GDB not provide this support for local
> > >   host ?
> > 
> > Simple: because no one wrote tracepoints support for native
> > debugging.
> 
> Right -- please contribute support for native tracepoints!
> 
> > >   2. Is it not the case that the features (supposed to
> > >   be) provided by tracepoints can be done using
> > >   breakpoint features only (for instance , we can
> > >   specify COMMANDS for  a breakpoint just as we can
> > >   specify ACTIONS for tracepoints) ?
> > 
> > Yes.  But tracepoints are supposed to be much more lightweight
> > (because only raw data is accumulated during the program's run, while
> > complicated and expensive computations like evaluation of arbitrary
> > expressions, are left for later).  So, theoretically, if tracepoints
> > were available for native debugging, one could perhaps debug programs
> > without disrupting their time scale too much, maybe even debug
> > real-time programs (well, one's allowed to dream once in a while,
> > right? ;-).
> 
> Actually, the tracepoint system *does* evaluate arbitrary expressions
> each time a tracepoint is hit.  The expressions are compiled to a
> bytecode which is pretty simple to interpret.  Here's why it's
> lightweight:
> - The bytecode has had all the symbolic work squeezed out of it ---
>   it's just a bunch of pretty standard machine-level operations on
>   machine words.  No name lookups, no type checking, etc.  So it can
>   run in much less memory and much less time than GDB's evaluator.
> - This means that it can be evaluated entirely on the target.  No
>   communication with the host is needed.  You can do a lot of
>   computation in the time it takes a byte to go across a serial line.
> 
> There are a bunch of ways we could support this on a native system:
> 
> - We could implement it as an extension to ordinary breakpoints:
>   hitting a tracepoint would stop the inferior; GDB would collect the
>   data, and then continue the inferior.  I think this might not be so
>   lightweight.
> 
> - We could implement a tracing agent that would actually live in the
>   inferior and catch some sort of trap.  This would be more complex,
>   but it would disturb the inferior less.

Or do it via dynamic code replacement at the start of functions. 
That's even lighter, though a bit hard to get right.

I hope to work on this - some day.  Gotta get through dwarf
improvements first :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer