From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15749 invoked by alias); 9 Jun 2008 22:40:46 -0000 Received: (qmail 15740 invoked by uid 22791); 9 Jun 2008 22:40:46 -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; Mon, 09 Jun 2008 22:40:28 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 68FCC3C1EB; Mon, 9 Jun 2008 15:40:26 -0700 (PDT) Subject: Re: GDB record patch 0.1.3.1 for GDB-6.8 release From: Michael Snyder To: Daniel Jacobowitz Cc: Pedro Alves , teawater , gdb-patches@sourceware.org, Thiago Jung Bauermann In-Reply-To: <20080609025953.GA1289@caradoc.them.org> References: <200805231746.23570.pedro@codesourcery.com> <200806090152.00220.pedro@codesourcery.com> <20080609025953.GA1289@caradoc.them.org> Content-Type: text/plain Date: Mon, 09 Jun 2008 22:56:00 -0000 Message-Id: <1213051226.3601.470.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/msg00174.txt.bz2 On Sun, 2008-06-08 at 22:59 -0400, Daniel Jacobowitz wrote: > On Mon, Jun 09, 2008 at 01:51:59AM +0100, Pedro Alves wrote: > > My idea is that support for reverse execution should be exposed by > > target methods and properties. Say target_can_reverse_p (), > > target_set_execution_direction (...) or similar. For native > > debugging, it might be possible to share most of the code > > between similar targets. > > I want to make sure everyone realizes that patches for this have > already been posted, by Michael Snyder. It was a while ago so it may > have fallen out of our institutional memory :-) I recently sent > Michael an updated version of his patches, off list. > > Perhaps we can get those in, providing the abstract methods and remote > protocol support, and then see what parts of the record patch it > simplifies? I also want to do this. I will begin looking into, at the least, creating a revised patch branch that brings the existing patches up to date. Then we can discuss importing them into the main trunk. I am sure that the gdb record patch will benefit.