From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16603 invoked by alias); 11 Jul 2004 22:49:23 -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 16546 invoked from network); 11 Jul 2004 22:49:21 -0000 Received: from unknown (HELO nick.uklinux.net) (194.247.51.141) by sourceware.org with SMTP; 11 Jul 2004 22:49:21 -0000 Received: by nick.uklinux.net (Postfix, from userid 501) id 9762C75FE0; Sun, 11 Jul 2004 23:18:18 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16625.48298.119562.285317@nick.uklinux.net> Date: Sun, 11 Jul 2004 22:49:00 -0000 To: jmolenda@apple.com Cc: alain@qnx.com, gdb@sources.redhat.com Subject: Re: MI level command X-SW-Source: 2004-07/txt/msg00103.txt.bz2 > > So would a patch implementing > > -gdb-mi-level > > ^done,level=1 > > be a good thing ? > It would probably help some, but I don't see it as solving the problem. The MI > version # changes very rarely, and individual MI commands can change quite a > bit within a single MI version. On the good side, the changes to MI commands' > output are mostly additional information that can be ignored if not recognized > (and, hopefully, worked around if absent). I agree. I don't have the resources to track different MI versions and hope to make the transition from annotations to a stable MI. > So anyway, Nick makes a similar change, but with the order of arguments being > "SHOW-VALUE VAROBJ-HANDLE". Ouch. He also added the --no-values and > --all-values command line arguments at the same time. I think I *did* have the arguments the other way round initially and Andrew Cagney advised me to reverse them. I may be wrong about that. In any case I don't really care which order they are in but clearly there should be consistency. Currently it seems to be a bit of a free for all but if Apple can provide a more rigorous standard then I will be happy to try to follow it. > I much prefer the -data-disassemble command where each piece of information is > passed with a separate command argument flag (except for its "mixed mode" > boolean integer as the optional last argument on the line, sigh). This is one command I find awkward as it doesn't do what the CLI command "disassemble" does. I guess it shows that we all want different things out of the same interface. Nick