This is the mail archive of the
gdb@sources.redhat.com
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" <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