This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Tracepoint enhancements
- From: Michael Snyder <msnyder at vmware dot com>
- To: Stan Shebs <stan at codesourcery dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Fri, 31 Oct 2008 13:39:11 -0700
- Subject: Re: Tracepoint enhancements
- References: <490B630F.8010008@codesourcery.com>
Stan Shebs wrote:
There is some interest in pumping up GDB's tracepoint capabilities, in
particular to make it more suitable for cross-debugging a target with
serious performance constraints. While a lot of the detail is centered
around making a faster stub and other low-level tweaks, we are going to
do MI for tracing finally, plus it's an opportunity to review the
existing trace commands and consider what interface changes are
desirable. In particular, we will want to think about how tracing should
interoperate with non-stop debugging and multi-process.
So the first question that comes to my mind is: how many people are
actually using the trace commands right now? If they're not being much
used, then we have more flexibility about making user-visible changes.
To my knowledge, I don't know of anybody, except possibly EMC.
Over the years, I've seen a (small) number of messages from people
saying they were considering or trying to implement a tracepoint
back-end, but I don't remember a lot of follow-up.
One possible change to consider is to merge tracepoint setting into
breakpoint setting. Among other benefits would be a single numbering
scheme for breakpoints and tracepoints, plus we will be able to share
some machinery and make things more consistent.
Just my personal opinion, I would find that confusing.
It seems useful to maintain a fairly sharp distinction
between breakpoints and tracepoints, since their behavior
is entirely different from both the implementation and the
user's point of view.
But I would not plan to make a fuss about it...
A bigger change would be to introduce a general notion of execution
history, which could subsume fork checkpoints and trace snapshots, maybe
tie into some versions of reverse debugging as well.
That could be interesting to talk about.
Right now, I think checkpoints are only implemented for native
linux, and maybe a few other (native) targets. Whereas tracepoints
are traditionally associated with remote targets.
I am very interested in defining a remote protocol that could
tell the remote target "take a checkpoint" or "restore to a
checkpoint". Ideally it should be entirely agnostic about how
a checkpoint is actually implemented.
I talked about this with somebody once (can't remember who),
but I remember the discussion got hung up over whether gdb or
the target should actually manage the list of checkpoint IDs.
My thinking is that gdb will probably want to number them with
simple ordinal numbers (1, 2, 3...) like breakpoints, but that
the target may have a different type of ID in mind (such as
process/fork IDs), and somebody will have to maintain a mapping.
Not very different from threads, actually...
What else should we be thinking about doing?
I have a vague recollection that the target-side expression
evaluation engine was incomplete with respect to floating point
arithmetic. I could be wrong.
I also recently tried to remember whether the "tfind" command
could accept an argument that meant "go back by N frames". I
know it can go forward by N frames, but it seems like backward
would be useful too.
One more thing, only vaguely related...
I've thought that if we had the ability to attach an expression
(in pcode such as we use for tracepoints) to a conditional breakpoint,
we could have the conditional evaluation be done on the target
rather than by gdb, which would be a big performance win for
conditional breakpoints or watchpoints.