From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29622 invoked by alias); 19 Aug 2009 20:03:01 -0000 Received: (qmail 29613 invoked by uid 22791); 19 Aug 2009 20:03:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Aug 2009 20:02:55 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 9CFCE45004; Wed, 19 Aug 2009 13:02:53 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost3.vmware.com (Postfix) with ESMTP id 9498ECD903; Wed, 19 Aug 2009 13:02:53 -0700 (PDT) Message-ID: <4A8C5997.1080705@vmware.com> Date: Wed, 19 Aug 2009 20:29:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Jakob Engblom CC: 'Hui Zhu' , "gdb@sourceware.org" Subject: Re: Simics & reverse execution References: <002001ca1f0e$4c9b74a0$e5d25de0$@com> <002101ca1f2e$746e1ad0$5d4a5070$@com> <200908171251.07179.pedro@codesourcery.com> <4A899E2E.6080203@vmware.com> <00b801ca1f74$e5610a90$b0231fb0$@com> <4A89B7E4.9010804@vmware.com> <027701ca209f$64c71ce0$2e5556a0$@com> <010601ca2106$90d41920$b27c4b60$@com> In-Reply-To: <010601ca2106$90d41920$b27c4b60$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-08/txt/msg00181.txt.bz2 Jakob Engblom wrote: > The key thing for me was to explain that the time scope of the reversible run is > potentially larger than what any particular gdb-remote connection sees: i.e., it > is nice if gdb would accept backing into "before it was attached" logically, and > not assume too much control over the reversing in itself. If I understand you correctly, I think there's no problem. You want to be able to reverse-continue to a point in the execution history that is earlier than when gdb attached -- right? Should be ok -- gdb doesn't really 'know' anything special about the point in "time" when it attached. > And that a probe for reversibility in gbd-remote would be a worthwhile addition > to the protocol. Sounds like a good idea. Maybe a 'q' query? "qReverse", maybe?