MI level command

MI level command

[Alain Magloire]

Yellow


Scenario:  We want to know wich level of MI that we are currently working in.
  This can allow to adjust what MI command to use and how to parse them.

Problems: No such command in MI and no GDB variable that we can test via -gdb-show.
  The version of  gdb
     gdb --version
  show different things in different distributions, sometimes it is a number based on date
  etc ...

So would a patch implementing

 -gdb-mi-level
 ^done,level=1

be a good thing ?

Re: MI level command

[Jason Molenda]

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

Re: MI level command

[Arnaud Charlet]

> 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.

Looks very useful indeed.

Any reason not to incorporate this function in the FSF version ?

Arno

Re: MI level command

[Bob Rossi]

On Sat, Jul 10, 2004 at 07:17:53PM +0200, Arnaud Charlet wrote:
> > 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.
> 
> Looks very useful indeed.
> 
> Any reason not to incorporate this function in the FSF version ?

I still think functions like this are only partly useful. The real
problem is that as a front end writer, even if the function exists,
there is no way of figuring out the I/O of the function. In some case's,
it's probably not even useful to know that a function exists, especially
as functions change through each release.

Bob Rossi

Re: MI level command

[Alain Magloire]

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

Re: MI level command

[Andrew Cagney]

> Yellow
> 
> 
> Scenario:  We want to know wich level of MI that we are currently working in.
>   This can allow to adjust what MI command to use and how to parse them.
> 
> Problems: No such command in MI and no GDB variable that we can test via -gdb-show.
>   The version of  gdb
>      gdb --version
>   show different things in different distributions, sometimes it is a number based on date
>   etc ...
> 
> So would a patch implementing
> 
>  -gdb-mi-level
>  ^done,level=1
> 
> be a good thing ?

This needs to be resolved.

I think its become clear that clients are choosing to support multiple 
debugger releases rather than certifying against a single debugger and 
mi version.  This is contrary to the expectation that the clients would 
tightly couple their front end to a specific GDB and MI version, and 
consequently, when starting GDB, specify a specific MI version.

Given this, we need to change the way versioning is handled.

- we can't create a situtation where GDB is required to retain existing 
[broken] behavior indefinitly

- we can certainly look for ways that let the client use both old and 
newer GDB's - the clients then get to decide how much backward 
incompatibility they wish to retain without imposing the burdon on GDB.

To that end:

-> we should probably implement significant command output (and more 
importantly input) changes by adding a new command.  A missing new 
command is easy to detect, just run it with no options.

-> minor output changes (new field for instance) do not need a new command

-> MI version changes tied to significant changes

Andrew

Re: MI level command

[Bob Rossi]

On Tue, Aug 24, 2004 at 06:03:25PM -0400, Andrew Cagney wrote:
> >Yellow
> >
> >
> >Scenario:  We want to know wich level of MI that we are currently working 
> >in.
> >  This can allow to adjust what MI command to use and how to parse them.
> >
> >Problems: No such command in MI and no GDB variable that we can test via 
> >-gdb-show.
> >  The version of  gdb
> >     gdb --version
> >  show different things in different distributions, sometimes it is a 
> >  number based on date
> >  etc ...
> >
> >So would a patch implementing
> >
> > -gdb-mi-level
> > ^done,level=1
> >
> >be a good thing ?
> 
> This needs to be resolved.
> 
> I think its become clear that clients are choosing to support multiple 
> debugger releases rather than certifying against a single debugger and 
> mi version.  This is contrary to the expectation that the clients would 
> tightly couple their front end to a specific GDB and MI version, and 
> consequently, when starting GDB, specify a specific MI version.
> 
> Given this, we need to change the way versioning is handled.
> 
> - we can't create a situtation where GDB is required to retain existing 
> [broken] behavior indefinitly
> 
> - we can certainly look for ways that let the client use both old and 
> newer GDB's - the clients then get to decide how much backward 
> incompatibility they wish to retain without imposing the burdon on GDB.
> 
> To that end:
> 
> -> we should probably implement significant command output (and more 
> importantly input) changes by adding a new command.  A missing new 
> command is easy to detect, just run it with no options.
> 
> -> minor output changes (new field for instance) do not need a new command
> 
> -> MI version changes tied to significant changes

Agreed, this would be a *great* step in the right direction. I propose
that for every mi command, we give the signature, so that the client
knows exactly what the command is capable of. Just saying that a command
is there is not good enough.

It's very similar to POSIX coming out with a standard that says, the
function named select and poll must be present and then a C programmer
trying to interface with that function.

Thanks,
Bob Rossi

Re: MI level command

[Alain Magloire]

> 
> > Yellow
> > 
> > 
> > Scenario:  We want to know wich level of MI that we are currently working in.
> >   This can allow to adjust what MI command to use and how to parse them.
> > 
> > Problems: No such command in MI and no GDB variable that we can test via -gdb-show.
> >   The version of  gdb
> >      gdb --version
> >   show different things in different distributions, sometimes it is a number based on date
> >   etc ...
> > 
> > So would a patch implementing
> > 
> >  -gdb-mi-level
> >  ^done,level=1
> > 
> > be a good thing ?
> 
> This needs to be resolved.
> 
> I think its become clear that clients are choosing to support multiple 
> debugger releases rather than certifying against a single debugger and 
> mi version.  This is contrary to the expectation that the clients would 
> tightly couple their front end to a specific GDB and MI version, and 
> consequently, when starting GDB, specify a specific MI version.
> 

Yes, some embedded platforms are still using old versions and for whatever
reasons and can not move the latest/greatest.  Frontends still need to cope
with this and detecting the version of MI will allow them to adjust.

> Given this, we need to change the way versioning is handled.
> 
> - we can't create a situtation where GDB is required to retain existing 
> [broken] behavior indefinitly
> 
> - we can certainly look for ways that let the client use both old and 
> newer GDB's - the clients then get to decide how much backward 
> incompatibility they wish to retain without imposing the burdon on GDB.
> 
> To that end:
> 
> -> we should probably implement significant command output (and more 
> importantly input) changes by adding a new command.  A missing new 
> command is easy to detect, just run it with no options.
> 
> -> minor output changes (new field for instance) do not need a new command
> 
> -> MI version changes tied to significant changes
> 

100% agreement, here 8-).

Thanks.

Re: MI level command

[Jason Molenda]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]


On Jul 11, 2004, at 3:18 PM, Nick Roberts wrote:

>> 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.

It's not really an important detail - my gripe is more with the general 
way that MI commands take their arguments and how they're extended over 
time to handle more behaviors.  There's no way you could have known 
that we did it differently in the Apple sources.

(and to merge the two, I changed our gdb to handle both argument 
styles, with the obvious problem that varobjs can't be named "1"/"0" 
'cause it's ambiguous.)


>> 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.


Yeah, in our version we extended the -data-disassemble command to have 
the CLI type behavior as well.  e.g. provide a start address and 
optionally the # of insns to disassemble, and -data-disassemble does 
what you'd expect.  i.e.


[-- Attachment #2: pa.txt --]
[-- Type: text/plain, Size: 3129 bytes --]

--- /Network/Servers/madrid/Volumes/huis/jmolenda/j/sware/gdb/src/gdb/mi/mi-cmd-disas.c	Mon Sep 30 08:57:26 2002
+++ mi-cmd-disas.c	Fri Feb  6 17:28:03 2004
@@ -35,8 +35,13 @@
    START-ADDRESS: address to start the disassembly at.
    END-ADDRESS: address to end the disassembly at.
 
-   or:
+   Optionally, you can leave out END-ADDRESS, in which case it
+   will disassemble the function around START-ADDRESS.  In this
+   case we will also accept the HOW_MANY argument to throttle
+   the disassembly display at that number of assembly lines.
 
+   or:
+   
    FILENAME: The name of the file where we want disassemble from.
    LINE: The line around which we want to disassemble. It will
    disassemble the function that contins that line.
@@ -51,8 +56,8 @@
 enum mi_cmd_result
 mi_cmd_disassemble (char *command, char **argv, int argc)
 {
-  enum mi_cmd_result retval;
-  CORE_ADDR start;
+/* APPLE LOCAL: hack to work around bug in our find_line_pc() replacement func */
+  CORE_ADDR start = 0;
 
   int mixed_source_and_assembly;
   struct symtab *s;
@@ -125,15 +130,22 @@ mi_cmd_disassemble (char *command, char 
   /* Allow only filename + linenum (with how_many which is not
      required) OR start_addr + and_addr */
 
+  /* APPLE LOCAL: Allow only the start addr, and interpret this to mean 
+     the same thing as in the disassemble command - disassemble the function
+     around the -s address.  */
+
   if (!((line_seen && file_seen && num_seen && !start_seen && !end_seen)
 	|| (line_seen && file_seen && !num_seen && !start_seen && !end_seen)
-	|| (!line_seen && !file_seen && !num_seen && start_seen && end_seen)))
+	|| (!line_seen && !file_seen && !num_seen && start_seen && end_seen)
+	|| (!line_seen && !file_seen && start_seen && !end_seen)))
     error
-      ("mi_cmd_disassemble: Usage: ( [-f filename -l linenum [-n howmany]] | [-s startaddr -e endaddr]) [--] mixed_mode.");
+      ("mi_cmd_disassemble: Usage: ( [-f filename -l linenum [-n howmany]] | [-s startaddr -e endaddr] | "
+       "[-s startaddr [-n howmany]]) [--] mixed_mode.");
 
   if (argc != 1)
     error
-      ("mi_cmd_disassemble: Usage: [-f filename -l linenum [-n howmany]] [-s startaddr -e endaddr] [--] mixed_mode.");
+      ("mi_cmd_disassemble: Usage: [-f filename -l linenum [-n howmany]] [-s startaddr -e endaddr] | "
+       "[-s startaddr [-n howmany]] [--] mixed_mode.");
 
   mixed_source_and_assembly = atoi (argv[0]);
   if ((mixed_source_and_assembly != 0) && (mixed_source_and_assembly != 1))
@@ -151,6 +163,13 @@ mi_cmd_disassemble (char *command, char 
       if (!find_line_pc (s, line_num, &start))
 	error ("mi_cmd_disassemble: Invalid line number");
       if (find_pc_partial_function (start, NULL, &low, &high) == 0)
+	error ("mi_cmd_disassemble: No function contains specified address");
+    }
+  else if (start_seen && !end_seen)
+    {
+      /* APPLE LOCAL: See above, if only start address, disassemble
+	 the function around the start address.  */
+      if (find_pc_partial_function (low, NULL, &low, &high) == 0)
 	error ("mi_cmd_disassemble: No function contains specified address");
     }
 

[-- Attachment #3: Type: text/plain, Size: 4 bytes --]




J

Re: MI level command

[Alain Magloire]

> 
> On Thu, Jul 08, 2004 at 07:33:17PM -0400, Alain Magloire wrote:
> > Yellow
> > 
> > 
> > Scenario:  We want to know wich level of MI that we are currently working in.
> >   This can allow to adjust what MI command to use and how to parse them.
> > 
> > Problems: No such command in MI and no GDB variable that we can test via -gdb-show.
> >   The version of  gdb
> >      gdb --version
> >   show different things in different distributions, sometimes it is a number based on date
> >   etc ...
> > 
> > So would a patch implementing
> > 
> >  -gdb-mi-level
> >  ^done,level=1
> > 
> > be a good thing ?
> 
> I like this idea a lot. I will need it when I start getting more work
> done on TGDB. However, there is another DRY problem. What functions act
> which way for which level?
> 

Agreed, it is a problem, I do not have any solutions.  For example
say thread-list-ids been crashing or misbehaved and the latest gdb fix the
problems ... For front-ends how to know this is fix ?

In theory the combination of version and the MI level should have done the trick.


> Basically, should every front end understand that
> -file-list-exec-source-files outputs just the files for level 1 but it
> also outputs the libraries the files belong to in level2?
> 
> One solution could be, for every MI function, we could generate a unique
> key. For example, mi1-file-list-exec-source-files,
> mi2-file-list-exec-source-files, ...
> This key would tell the front end to use that particular parsing
> function when checking the output of -file-list-exec-source-files.
> 
> Is this to wacky?
> 

It sounds like a lot of maintainance.
How about for every release of gdb we bumb up a number ?
Say MI level could return {0,1,2,..} and MI gdb version could return something else.
So the unique key is for a release and all commands ... basically having taking the role of version.

So why is "version" so mangle in gdb ?

Re: MI level command

[Nick Roberts]

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