This is the mail archive of the 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

Jakob Engblom wrote:
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...

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

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

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