This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Tracepoint enhancements
- From: "Jakob Engblom" <jakob at virtutech dot com>
- To: "'Michael Snyder'" <msnyder at vmware dot com>
- Cc: "'Stan Shebs'" <stan at codesourcery dot com>, <gdb at sourceware dot org>
- Date: Mon, 3 Nov 2008 19:52:37 +0100
- Subject: RE: Tracepoint enhancements
- References: <490B630F.8010008@codesourcery.com> <490B6CEF.2000003@vmware.com> <003e01c93d7e$94eb1de0$bec159a0$@com> <490F40CB.60205@vmware.com>
> > 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.
I think that is a bad idea to assume there is only one time or one instruction
count in the target. It could be a multicore target with lots of CPUs running
around... so let the backend handle that in a symbolic way rather than assume
anything about what it means.
> > 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.
That is a decent idea.
> >> 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".
Sorry, misunderstood. Thanks.
/jakob