From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16284 invoked by alias); 18 Oct 2008 01:44:21 -0000 Received: (qmail 16273 invoked by uid 22791); 18 Oct 2008 01:44:20 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.189) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 18 Oct 2008 01:43:45 +0000 Received: by ti-out-0910.google.com with SMTP id d10so431746tib.12 for ; Fri, 17 Oct 2008 18:43:42 -0700 (PDT) Received: by 10.110.57.6 with SMTP id f6mr3458010tia.46.1224294222154; Fri, 17 Oct 2008 18:43:42 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Fri, 17 Oct 2008 18:43:42 -0700 (PDT) Message-ID: Date: Sat, 18 Oct 2008 01:44:00 -0000 From: teawater To: "Eli Zaretskii" Subject: Re: [reverse RFC] Add documentation for process record and replay Cc: "Jakob Engblom" , msnyder@vmware.com, gdb-patches@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00cd01c9308f$002aa0a0$007fe1e0$@com> 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/msg00455.txt.bz2 Replay mode is designed to replay the inferior execute behaver (Now, it just care about registers and memory change. It will add more in the future) in before. So it don't replay what you were talk about. On Sat, Oct 18, 2008 at 03:47, Eli Zaretskii wrote: >> From: "Jakob Engblom" >> Cc: , >> >> Date: Fri, 17 Oct 2008 21:31:36 +0200 >> >> > > > 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. > > We should at least describe a couple of possibilities and tell the > reader to consult the documentation of the particular target for the > full details. >