From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8413 invoked by alias); 20 Sep 2005 23:11:35 -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 8187 invoked by uid 22791); 20 Sep 2005 23:11:04 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 20 Sep 2005 23:11:04 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2005 16:11:02 -0700 X-IronPort-AV: i="3.97,128,1125903600"; d="scan'208"; a="343724954:sNHT29258836" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8KNAY4r001884; Tue, 20 Sep 2005 16:11:00 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 16:10:57 -0700 Received: from [128.107.165.235] ([128.107.165.235]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 16:11:02 -0700 Message-ID: <43309700.6010507@cisco.com> Date: Tue, 20 Sep 2005 23:11:00 -0000 From: Michael Snyder User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 MIME-Version: 1.0 To: gdb@sources.redhat.com CC: shebs@apple.com Subject: Re: Using reverse execution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00147.txt.bz2 > Depending on the answers, the project could be fatally flawed. > For instance, if the ability to undo system calls is critical > for usability, that pretty much relegates reversal to simulator > targets only - not interesting for my user base. That's why I > wanted to talk about usage patterns; if users don't need the > debugger to do the incredibly hard things, then we can get to > something useful sooner. Here's the thing, though, Stan -- We can separate the debugger implementation questions from the target-side implementation questions. Whether I/O can be "undone", whether system calls can be reversed over, even whether the target can proceed forward again from a point that it has reversed back to -- these are all things about which gdb need not concern itself. They're target-side details. Think about forward execution. Does gdb know anything about system calls? In general, not. Does it know anything about I/O? Definitely not, except in some special cases. GDB knows about step, continue, and why-did-we-stop? Those are its primatives. If we make the CORE PART of gdb do nothing more than use similar primatives for backward debugging, then it will "just work". I know this, 'cause I've done it. We may need to build some more intimate details into SOME gdb back-ends, or implement a separate module that can do certain things such as checkpoints for a target that can't do them for itself -- but the core part of gdb doesn't need to know about that, and those considerations need not hold up the development of reverse execution in the core part of gdb. Separate the debugging of reverse-execution from the question of how the reverse-execution is to be done. I know, you need to consider both, and there's definitely cross-over, but what I am saying is that we CAN separate them, and that gdb will be better if we do. The part of gdb that controls execution (infrun and infcmd, for instance) SHOULD not know how the backend or the target "works". The target, on the other hand, may have lots of capabilities, and it may not. Maybe it can only "back up" until the first system call, and then it gives up. Well, then gdb just needs to know how to handle a target that can do some reverse executing, but then can't do more. That's general -- because another target may have a "buffer" of saved state for reverse execution, and it may eventually reach the beginning of that buffer. Infrun doesn't necessarily need to know WHY the target can't go backward any more, just that it can't. Although of course we might encode some common reasons and give some meaningful failure message, it isn't essential to the implementation of reverse debugging.