This is the mail archive of the
mailing list for the GDB project.
Re: Tracepoint enhancements
- From: Michael Snyder <msnyder at vmware dot com>
- To: Jakob Engblom <jakob at virtutech dot com>
- Cc: 'Stan Shebs' <stan at codesourcery dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Mon, 03 Nov 2008 10:19:55 -0800
- Subject: Re: Tracepoint enhancements
- References: <490B630F.firstname.lastname@example.org> <490B6CEF.email@example.com> <003e01c93d7e$94eb1de0$bec159a0$@com>
Jakob Engblom wrote:
Just my personal opinion, I would find that confusing.
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.
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...
In a simulator, they might be the same. In both cases, the main mechanism is
noting that you reach a certain place in the code or read or write som memory
position. Whether you then note it down and continue or stop execution or call
some callback does not matter. So they can be very much the same.
That could be interesting to talk about.
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.
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.
If by checkpoint you mean "some point inside the execution of a single program"
this is also a nice fit with simulators (and I presume VmWare as well, if we use
its snapshotting ability for this). I think this is a very good idea that works
very well with a smart remote target.
Yes, that's what I meant. A "point in time" in the execution
history, something that could be represented eg. by a cycle count
or instruction count, rather than just by a PC.
Something corresponding to a snapshot or bookmark.
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.
The target might have its own interface for looking at such checkpoints... so I
think passing name strings make the most sense. In Simics, for example,
bookmarks as we call them have names and that is how we work with them.
Right -- so for you an internal representation might look like a string.
For VMware, it would look like a pair of integers. If we did an
implementation linux gdbserver, in which gdbserver did the "fork
trick" (like gdb does now), then the internal representation would
be a process ID.
But for all of these, gdb might keep an external representation
that just looked like a counting integer -- as it does for breakpoints
and threads. That way the user would have a common interface
(eg. "restore 3"), no matter which target.
Not very different from threads, actually...
I think it is. It is a snapshot of the system state that you can back to, not
really a thread. Only if you consider the odd Linux implementating with fork et
al are they the same.
Sorry, I just meant "like threads in that we have a counting
integer representation on the GDB side, even though there are
various internal representations on the target side".