From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18287 invoked by alias); 17 Oct 2008 19:44:05 -0000 Received: (qmail 18279 invoked by uid 22791); 17 Oct 2008 19:44:05 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Oct 2008 19:43:30 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 849DA6001; Fri, 17 Oct 2008 12:43:27 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost2.vmware.com (Postfix) with ESMTP id 7BDEC8E578; Fri, 17 Oct 2008 12:43:27 -0700 (PDT) Message-ID: <48F8E9FB.2020702@vmware.com> Date: Fri, 17 Oct 2008 19:44:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Jakob Engblom CC: 'Eli Zaretskii' , 'teawater' , "gdb-patches@sourceware.org" Subject: Re: [reverse RFC] Add documentation for process record and replay References: <48F63B15.3070705@vmware.com> <00cd01c9308f$002aa0a0$007fe1e0$@com> In-Reply-To: <00cd01c9308f$002aa0a0$007fe1e0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00440.txt.bz2 Jakob Engblom wrote: >>>> signals? crashes? etc. Are there things that simply cannot be >>>> reproduced exactly, due to fundamental limitations of the replay >>>> target? >> Do you have an opinion about these concerns? > > I would like to jump in here and point out that this will depend on the nature > of the target. Simics, and presumably other full-system simulation solutions, > can replay the entire IO of a machine. This includes any external IO that is > asynch to the simulator execution (such as network packets and user input). > Between machines in a simulated network of machines, replay is obviously > perfect. > > If you try to do this on a live machine, it is a bit more tricky. > > So this is best left to the underlying mechanism, in my experience. Absolutely. But here, we are discussing the documentation for one particular mechanism, what we're referring to as "process record and replay". This only records and replays the execution of a single process, so it might be a good idea to document its specific capabilities and limitations in this area.