From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24205 invoked by alias); 12 Jul 2004 17:38:53 -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 24185 invoked from network); 12 Jul 2004 17:38:52 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 12 Jul 2004 17:38:52 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id MAA20084 for ; Mon, 12 Jul 2004 12:58:14 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id NAA27485 for gdb@sources.redhat.com; Mon, 12 Jul 2004 13:38:50 -0400 Message-Id: <200407121738.NAA27485@smtp.ott.qnx.com> Subject: Re: MI level command To: jmolenda@apple.com (Jason Molenda) Date: Mon, 12 Jul 2004 17:51:00 -0000 From: "Alain Magloire" Cc: gdb@sources.redhat.com In-Reply-To: <83333EB4-D1E9-11D8-B84C-000A9569836A@apple.com> from "Jason Molenda" at Jul 09, 2004 01:49:46 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00111.txt.bz2 > > > On Jul 8, 2004, at 4:33 PM, Alain Magloire wrote: > > > 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, Well it already did ... 3 times level 0, 1, 2 > 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). > How about bug fixes and misbehaved like Bob Rossi was mentionning. How are you recognize this in the front end ? > My bigger concern is the way MI commands are invoked -- many of the > commands are (IMHO) poorly written, either written as if a human was > typing them in or using numeric constants positionally to indicate > different behaviors. Sometimes the entropy is reversed, e.g. Nick > Roberts' addition of the "--all-values", "--no-values", and > "--simple-values" arguments to -stack-list-locals was a change in the > right direction. But consider -var-list-children. Long ago at Apple > we'd extended this command so that the arguments to -var-list-children > was "VAROBJ-HANDLE SHOW-VALUE" where SHOW-VALUE was an integer with > magical meanings, akin to what -stack-list-locals did (we had a '2' > that did created varobj's and the like). > Yes, I agree, there are inconsistencies in the commands, some understand "--" as as separator some others do not. Some understand ""(double quotes) as way to group a phrase some other do not. Some understand the escape char slash (\) some ... do not. Some commands insist when passing spaces part of the argument that you use quotes ... well some other if you do will return an error etc ... ... Not that I'm complaining 8-) > 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 don't mean to rag on Nick of course, but this illustrates the limited > extensibility of MI commands that work like this. And I certainly > don't mean to imply that Apple hasn't made similar misjudgements in our > own MI commands -- just yesterday I was looking at an MI command that > takes a thread number, a source filename, and a line number (so the > user can move the PC around in a function), and the command looks like > "-thread-set-pc THREADNO SOURCE:LINE". And now is the time in our > program when we parse. > > 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). > > > Oh, I got a little off topic. > Not at all, you are bang on. > BTW one convenient thing we have in the Apple gdb is a > -mi-verify-command MI command, so the GUI can see if a given command is > available or not. It's very helpful, and the implementation is a snap, > of course. > See Bob Rossi's followup on this. Technically with a correct "MI Level" and "GDB Version" a front-end should be able to know what is available and what is not. Still it could be a usefull tool in the front-ends in our quest to tame MI. > enum mi_cmd_result > mi_cmd_mi_verify_command (char *command, char **argv, int argc) > { > char *command_name = argv[0]; > struct mi_cmd *cmd; > > if (argc != 1) > error ("mi_cmd_mi_verify_command: Usage: MI_COMMAND_NAME."); > > cmd = mi_lookup (command_name); > > ui_out_field_string (uiout, "name", command_name); > if (cmd != NULL) > { > ui_out_field_string (uiout, "defined", "true"); > ui_out_field_string (uiout, "implemented", > ((cmd->cli.cmd != NULL) || > (cmd->argv_func != NULL) || > (cmd->args_func != NULL)) ? "true" : "false"); > } > else > { > ui_out_field_string (uiout, "defined", "false"); > } > > return MI_CMD_DONE; > } > >