From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23222 invoked by alias); 16 Sep 2005 14:00:40 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23200 invoked by uid 22791); 16 Sep 2005 14:00:32 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 16 Sep 2005 14:00:32 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j8GE0REo008471; Fri, 16 Sep 2005 07:00:27 -0700 (PDT) Received: from [17.219.198.182] (unknown [17.219.198.182]) by relay5.apple.com (Apple SCV relay) with ESMTP id D29EA324016; Fri, 16 Sep 2005 07:00:26 -0700 (PDT) Message-ID: <432ACFFB.9040204@apple.com> Date: Fri, 16 Sep 2005 14:00:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Using reverse execution References: <432628AA.2040808@apple.com> <43277083.1040708@apple.com> <4328A574.5080906@apple.com> <43290862.9040204@apple.com> <4329D5A3.8030202@apple.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00115.txt.bz2 Eli Zaretskii wrote: > >Anyway, I really don't understand why we need to discuss all this at >such length. Either there is a volunteer who is ready to do the job >of adding this, or there isn't. In the latter case, there's no sense >arguing about the value of the feature; in the former case, will we >really consider rejecting the patches that implement the feature >because some of us are unsure how useful it will be? > > I must not be getting my point across very well then. Apple is quite interested in getting reverse execution going outside of the simulator context, and I've been playing with some prototype machinery. However, it's clear that a full-blown handles-every-situation implementation will require a huge amount of kernel hacking in addition to the GDB part. I don't want to get into a situation like that of tracepoints, where the feature ultimately falls by the wayside because it's too narrow in applicability and implementation. So I'm not questioning the value of the feature, but trying to get a sense of the user requirements. Undoing a single a=b+c is relatively easy, and my prototype can do that now, but reversing through 15 minutes of iTunes usage is fiendishly hard, and would require a major commitment by Apple involving multiple software groups. The level of effort I'll be able to get depends on what we think the requirements look like. This is a rare opportunity to weigh in on a feature *before* it's implemented; an unfamiliar situation I know :-) , but something people ought to take advantage of rather than brush off. A lot of past GDB projects would have come out better had there been open discussion earlier in the process. Stan