From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15168 invoked by alias); 3 Jul 2008 01:56:06 -0000 Received: (qmail 15083 invoked by uid 22791); 3 Jul 2008 01:56:05 -0000 X-Spam-Check-By: sourceware.org Received: from rv-out-0708.google.com (HELO rv-out-0708.google.com) (209.85.198.251) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Jul 2008 01:55:39 +0000 Received: by rv-out-0708.google.com with SMTP id b17so612941rvf.48 for ; Wed, 02 Jul 2008 18:55:37 -0700 (PDT) Received: by 10.141.79.12 with SMTP id g12mr4783795rvl.87.1215050137337; Wed, 02 Jul 2008 18:55:37 -0700 (PDT) Received: by 10.141.32.18 with HTTP; Wed, 2 Jul 2008 18:55:37 -0700 (PDT) Message-ID: Date: Thu, 03 Jul 2008 01:56:00 -0000 From: teawater To: "Michael Snyder" Subject: Re: [RFC/RFA] gdbreplay V2.0 Cc: gdb@sourceware.org, gdb-patches@sourceware.org In-Reply-To: <1214974158.3601.1582.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1214974158.3601.1582.camel@localhost.localdomain> 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-07/txt/msg00027.txt.bz2 It can work with reverse command of "msnyder-reverse-20080609-branch"? On Wed, Jul 2, 2008 at 12:49, Michael Snyder wrote: > Here's a new contribution -- I call it gdb-freeplay, an > improved and less restrictive version of gdbreplay. Its > something I've been playing around with for some time now. > > This is a remote protocol logger/replayer, that works in > principal just like gdbreplay -- it even uses the same > logfiles, with no changes or enhancements. > > However, where gdbreplay constrains you in the replay session > to giving *exactly* the same commands, in *exactly* the same > sequence, as were used in the recorded session, gdb-freeplay > frees you of that constraint -- you can change the order of > the commands, or skip them entirely, even skip ahead past an > arbitrary number of execution events to get to the "interesting" > ones. > > You use step and next just like you did in the recorded > session, but now you can set a breakpoint and continue on > ahead to a later part of the session, even if you did not > do so in the original session. You can even next over a > function call that you originally stepped into -- so long > as you also stepped out of it. Or you can skip out with > "finish", even if you continued to debug the function > interminably in the original session. > > You can print any variable(s) or registers that you > examined before, in any order, even combine them into > expressions that were not used in the recorded session > (so long as all the values of the expression were evaluated). > In many ways, it's a lot like tracepoint debugging. > > I picture it being useful for gdb testing -- we might > even create hand-crafted "sessions" and use it to play > them back to explicitly test parts of the remote protocol. > > I can also picture a user sending you a binary and a > recorded log in which a bug happened -- you could debug > it even with a cross-debugger, lacking the appopriate > hardware (or simulator or what have you) -- and even if > the recorded log was 50 megabytes long, you could skip > ahead to the interesting bits. > > But frankly, I just wrote it because it was fascinating to do... > > Michael > > PS I've already written back-ends for x86, MIPS64, and x86-64. > Most other target architectures should be fairly easy to add, > and it will work with anything that uses the remote protocol. > >