This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI level command
- From: Jason Molenda <jmolenda at apple dot com>
- To: Alain Magloire <alain at qnx dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 9 Jul 2004 13:49:46 -0700
- Subject: Re: MI level command
- References: <200407082333.TAA25718@smtp.ott.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, 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).
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).
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.
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.
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;
}