This is the mail archive of the
mailing list for the GDB project.
Re: Tracepoint support in Cygnus GDB ?
On Wed, Sep 24, 2003 at 05:38:08PM -0500, Jim Blandy wrote:
> "Eli Zaretskii" <firstname.lastname@example.org> writes:
> > > Date: Wed, 24 Sep 2003 16:09:49 +0530
> > > From: Saravanan <email@example.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
> - 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.
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 :)
MontaVista Software Debian GNU/Linux Developer