This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Tracepoint support in Cygnus GDB ?
"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.