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: Simics & reverse execution


Jakob Engblom wrote:
anything
in
the backend, and let it worry about setting up times on multiple
processors,
multiple machines, or hardware recorders.
Ok, yes, I see what you're getting at here: bookmarks might be more
easily implemented in some targets than some global linear notion of
time.
Not quite... but it lets us get some use out of time in gdb without
introducing
a time concept. As I said, if we let the backend generate bookmarks, we can
get
to any time precision we want by pushing bookmarks from the backend.
Withtout
gdb having to understnad time.
Ah, the discussion comes back to where we started :)

Sincere apologies if I'm being stupid here, but I'm still struggling to
understand you.  i.e. I still don't understand why "get-time/set-time"
commands require that gdb gains any notion of time.

I think that is safe... but Michael Snyder was very clear that this had some
major issues as I understood it?

What I think I said was that gdb doesn't currently have any knowledge about time, and that I don't believe it needs to (other than to do what you specifically want to do).

You mentioned earlier that a target might want routinely to generate
bookmarks (e.g. every 10ms).  If that target numbered those bookmarks
1,2,3,4,etc then it would have exactly the notion of time that I'm
asking for here.

Yes, but it is done without any time representation at the gdb side of things.

This is not what I had in mind when I said "bookmark". I can see the utility of this concept, but I'd rather call it something else to distinguish the two.

The concept that I was thinking about as "bookmark" was a
relatively small number of discrete points in the execution
trace that gdb would keep track of in a list, in response to
explicit, discrete user requests.  Like breakpoints or checkpoints.

Something that the target generates a large number of, automatically
or at discrete intervals or something, sounds to me a little more
similar to tracepoints.  Maybe we could talk about using something
a little more like tracepoint semantics for that.

I don't follow.  If we had "get-time/set-time" commands, these could be
proxied by gdb straight to the target.  Thus gdb remains stateless in
this regard, and blissfully unaware of any notion of jumping around in
time.  All gdb needs to know is that "set-time" will change the
target's state, but that's no different to regular continue or step.

Yes, but it does invite for time to become more part of the state.

It's a hell of an interesting idea -- I can certainly understand why you're interested in it. But I don't think it's a requirement, for the simple concept of bookmarks.


Note that I am all for this, but I can see how it quickly degenerates into a
major design issue with


""get-time -thread x" ... how is THAT done?" ... etc ...
Hopefully Michael can clarify, but I thought he was agreeing that we
don't want to teach gdb about the concept of time (not yet anyway),
which I also totally agree with.

OK. All on the same plate.
My proposal is that a "timestamp" (i.e. what "get-time" returns) would
be very like a "bookmark", except:

(a) not precise like a bookmark (e.g. if "get-time" returns timestamp X,
then a subsequent "set-time" will take you close to time X, but not
necessarily exactly at time X)

Interesting idea to make this fuzzy. I can see a problem with this: unless your
backend has its own UI where you CAN check the precise time, this invites user
confusion. I often find myself carefully stepping back and forth very precise
cycle counts to observer what is going on... and this fuzzy time would not let
me do that. It also means that when execution stops after a "set-time" command,
you really don't know where you are :)


Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech Direct: +46 8 690 07 47 Drottningholmsvägen 22 Mobile: +46 709 242 646 11243 Stockholm Web: www.virtutech.com Sweden
________________________________________________________


/jakob




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