Re: Tracepoint support in Cygnus GDB ?

[Jim Blandy <jimb at redhat dot com>]

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

> >   3. Does tracepoint use the same TRAP (or ILLEGAL )
> >   instruction mechanism for tracepoints as it does for
> >   breakpoints?
> 
> IIRC, yes.

Yep.