From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29075 invoked by alias); 12 Jun 2008 18:30:14 -0000 Received: (qmail 29063 invoked by uid 22791); 12 Jun 2008 18:30:13 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Jun 2008 18:29:55 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id A91B23B8C4; Thu, 12 Jun 2008 11:29:53 -0700 (PDT) Subject: Re: GDB record patch 0.1.3.1 for GDB-6.8 release From: Michael Snyder To: teawater Cc: Pedro Alves , gdb-patches@sourceware.org, Thiago Jung Bauermann In-Reply-To: References: <200805231746.23570.pedro@codesourcery.com> <200806090152.00220.pedro@codesourcery.com> <1213204275.3601.605.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 13 Jun 2008 06:08:00 -0000 Message-Id: <1213295393.3601.669.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) 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-06/txt/msg00235.txt.bz2 Good --- making some good progress toward testing it. At a fairly basic level, it seems to work, but there may have been a little bit-rot around the most tricky bits (stepping backward in and out of functions, that sort of thing). Hui, you might look at isolating just the "set exec-direction" part and the target bits. Those might integrate well with what you are doing. On Thu, 2008-06-12 at 13:50 +0800, teawater wrote: > Thanks Michael, > > I've got it and read it. :) > > Hui > > On Thu, Jun 12, 2008 at 01:11, Michael Snyder wrote: > > On Wed, 2008-06-11 at 15:45 +0800, teawater wrote: > >> Hi Pedro, > >> > >> > Don't worry, it's really more about code reorganization, than > >> > rewriting. :-) > >> > > >> > You have two major components in your patch. > >> > > >> > 1 - The record/replay component > >> > 2 - The inferior control in reverse execution mode. > >> > > >> > I'm suggesting to split those up, and make them communicate > >> > with an abstracted interface (target methods). In addition, > >> > make the record support a layer on top of the > >> > forward-execution-only debugging targets (of course, defering > >> > much to the arch support). > >> > > >> Michael Snyder is think about it too. He make a rev interface in > >> before. I will try to use it. > > > > Hui, > > > > I've created a new branch in which I've hoisted my old > > reverse-debugging changes into the current codebase. > > It compiles, but I haven't had a chance to test it yet > > to see if it actually works in reverse. > > > > You might like to take a look at it, to get an idea of > > the direction we were most recently headed -- maybe diff > > it against the base to look at the changes. > > > > Branch name: msnyder-reverse-20080609-branch > > > > > > > >