From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14369 invoked by alias); 6 Feb 2009 04:11:43 -0000 Received: (qmail 14361 invoked by uid 22791); 6 Feb 2009 04:11:42 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Feb 2009 04:11:36 +0000 Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id n164BXm7029869 for ; Thu, 5 Feb 2009 20:11:33 -0800 Received: from rv-out-0506.google.com (rvfb25.prod.google.com [10.140.179.25]) by wpaz21.hot.corp.google.com with ESMTP id n164BUoY021759 for ; Thu, 5 Feb 2009 20:11:30 -0800 Received: by rv-out-0506.google.com with SMTP id b25so635895rvf.37 for ; Thu, 05 Feb 2009 20:11:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.115.20 with SMTP id s20mr604080rvm.255.1233893489785; Thu, 05 Feb 2009 20:11:29 -0800 (PST) In-Reply-To: <200902051239.27523.vladimir@codesourcery.com> References: <49463870.6080302@virtutech.com> <000a01c960f1$2c88d6c0$859a8440$@com> <200902051239.27523.vladimir@codesourcery.com> Date: Fri, 06 Feb 2009 04:11:00 -0000 Message-ID: Subject: Re: reverse for GDB/MI From: Doug Evans To: Vladimir Prus Cc: Jakob Engblom , Tomas Holmberg , gdb-patches@sources.redhat.com Content-Type: text/plain; charset=ISO-8859-1 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: 2009-02/txt/msg00148.txt.bz2 On Thu, Feb 5, 2009 at 1:39 AM, Vladimir Prus wrote: > It seems to be that it's best to have some structure in MI commands and flags. > Say, we have continue and reverse-continue. What if you want some other form > of continue, say "continue for N seconds". Should we have then: > > continue > reverse-continue > timed-continue > reverse-timed-continue > > ? That would be fairly cumbersome. Also, the --reverse option can be documented > with a single paragraph, whilst individual commands should all have individual > documentation. timed-continue could take a negative argument to go backwards. [fwiw, I'm in the camp that dislikes --reverse too] > To summarize, I would like the patch to be adjusted in the following way: > > 1. Use --reverse option > 2. Arrange for --exec-step, and similar, to ignore 'set exec-direction', > since all new MI commands should strive to be stateless. This, of course, > will mean that one cannot get existing frontend to do reverse step by > typing a command into CLI console, but it is not obvious if existing > frontend will work without modification anyway. Can we remove exec-direction altogether? 1/2 :-)