[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb
Subject:    Re: Simics & reverse execution
From:       Michael Snyder <msnyder () vmware ! com>
Date:       2009-09-17 3:07:09
Message-ID: 4AB1A7DD.4040803 () vmware ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]