This is the mail archive of the gdb@sourceware.org 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 enhancements


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.



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