From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26501 invoked by alias); 6 Jul 2005 14:02:37 -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 26480 invoked by uid 22791); 6 Jul 2005 14:02:32 -0000 Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 06 Jul 2005 14:02:32 +0000 Received: by NIMBUS with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jul 2005 10:02:31 -0400 Message-ID: <1578FF984ABAD411AFA5000102C4BB5B11595C19@NIMBUS> From: Alain Magloire To: Karganov Konstantin , Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: RE: MI usage inside a user-defined commands Date: Wed, 06 Jul 2005 14:02:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2005-07/txt/msg00041.txt.bz2 > > > > The ability to use CLI syntax in MI mode is documented in the manual as > > an unsupported, transitional feature. > It is documented, that "MI accepts existing CLI commands" (section 24.4) > and nothing is said about "unsupported" or "transitional" :) > > > it's not to be used by frontends. > That is clear, since the output format will be the mess of CLI and MI > output. > It is also practical, since not all MI Commands are implemented. So if you want to do something with signals, the backend may not have a Choice then to fallback to CLI. Also note that mi2 has -interpreter-exec to allow the use of CLI. The problem with that is the lost of synchronization state.