This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tracepoint support in Cygnus GDB ?

"Eli Zaretskii" <> writes:
> > Date: Wed, 24 Sep 2003 16:09:49 +0530
> > From: Saravanan <>
> >   
> >   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
- 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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]