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


> > 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


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