Re: MI level command

["Alain Magloire" <alain@qnx.com>]

> 
> 
> 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;
> }
> 
>