[RFA] set debug mi

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFA] set debug mi

Michael Snyder-5
Anybody think this is useful?

2007-04-11  Michael Snyder  <[hidden email]>

        * mi/mi-main.c (print_mi_command, print_mi_status): New functions.
        (captured_mi_execute_command): Call those if mi_debug_p is true.
        (mi_execute_cli_command): Make debugging output more concise.
        (show_mi_debug): New function.
        (_initialize_mi_main): Add "set/show debug mi" command.

Index: mi-main.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-main.c,v
retrieving revision 1.95
diff -p -r1.95 mi-main.c
*** mi-main.c 10 Apr 2007 14:53:46 -0000 1.95
--- mi-main.c 11 Apr 2007 23:28:04 -0000
***************
*** 25,30 ****
--- 25,31 ----
  /* Work in progress.  */
 
  #include "defs.h"
+ #include "gdbcmd.h"
  #include "target.h"
  #include "inferior.h"
  #include "gdb_string.h"
*************** struct captured_mi_execute_command_args
*** 86,94 ****
    struct mi_parse *command;
  };
 
- int mi_debug_p;
  struct ui_file *raw_stdout;
 
  /* This is used to pass the current command timestamp
     down to continuation routines.  */
  static struct mi_timestamp *current_command_ts;
--- 87,144 ----
    struct mi_parse *command;
  };
 
  struct ui_file *raw_stdout;
 
+ /* Non-zero tells MI to output debugging info.  */
+ int mi_debug_p;
+
+ /* MI debugging output routines.  */
+ static void
+ print_mi_command (struct mi_parse *cmd, struct ui_file *out)
+ {
+   int i;
+
+   fprintf_unfiltered (out, " token='%s' cmd='%s' (%s)",
+      cmd->token, cmd->command,
+      cmd->op == MI_COMMAND ? "MI_COMMAND" :
+      cmd->op == CLI_COMMAND ? "CLI_COMMAND" :
+      "<unknown op>");
+
+   if (cmd->args && cmd->args[0])
+     fprintf_unfiltered (out, " args='%s'", cmd->args);
+
+   for (i = 0; i < cmd->argc; i++)
+     fprintf_unfiltered (out, "\n\t argv[%d] = '%s'", i, cmd->argv[i]);
+
+   fprintf_unfiltered (out, "\n");
+   gdb_flush (out);
+ }
+
+ static void
+ print_mi_status (enum mi_cmd_result result,
+ struct mi_parse *cmd,
+ struct ui_file *out)
+ {
+   switch (result) {
+   case MI_CMD_DONE:
+     fprintf_unfiltered (out, "-token '%s' returned '^done'\n",
cmd->token);
+     break;
+   case MI_CMD_FORGROUND:
+   case MI_CMD_ERROR:
+     fprintf_unfiltered (out, "-token '%s' returned '^error', %s\n",
+ cmd->token, mi_error_message);
+     break;
+   case MI_CMD_QUIET:
+     fprintf_unfiltered (out, "-token '%s' returned quietly.\n",
cmd->token);
+     break;
+   default:
+     fprintf_unfiltered (out, "-token '%s' returned unknown ret
code.\n",
+ cmd->token);
+     break;
+   }
+   gdb_flush (out);
+ }
+
  /* This is used to pass the current command timestamp
     down to continuation routines.  */
  static struct mi_timestamp *current_command_ts;
*************** captured_mi_execute_command (struct ui_o
*** 1068,1082 ****
 
    struct mi_timestamp cmd_finished;
 
    switch (context->op)
      {
 
      case MI_COMMAND:
        /* A MI command was read from the input stream.  */
-       if (mi_debug_p)
- /* FIXME: gdb_???? */
- fprintf_unfiltered (raw_stdout, " token=`%s' command=`%s' args=`%
s'\n",
-    context->token, context->command, context->args);
        /* FIXME: cagney/1999-09-25: Rather than this convoluted
           condition expression, each function should return an
           indication of what action is required and then switch on
--- 1118,1131 ----
 
    struct mi_timestamp cmd_finished;
 
+   if (mi_debug_p)
+     print_mi_command (context, gdb_stdlog);
+
    switch (context->op)
      {
 
      case MI_COMMAND:
        /* A MI command was read from the input stream.  */
        /* FIXME: cagney/1999-09-25: Rather than this convoluted
           condition expression, each function should return an
           indication of what action is required and then switch on
*************** captured_mi_execute_command (struct ui_o
*** 1091,1096 ****
--- 1140,1148 ----
        if (do_timings)
            timestamp (&cmd_finished);
 
+       if (mi_debug_p)
+ print_mi_status (args->rc, context, gdb_stdlog);
+
        if (!target_can_async_p () || !target_executing)
  {
   /* Print the result if there were no errors.
*************** captured_mi_execute_command (struct ui_o
*** 1148,1153 ****
--- 1200,1208 ----
  argv[1] = context->command;
  args->rc = mi_cmd_interpreter_exec ("-interpreter-exec", argv, 2);
 
+ if (mi_debug_p)
+  print_mi_status (args->rc, context, gdb_stdlog);
+
  /* If we changed interpreters, DON'T print out anything.  */
  if (current_interp_named_p (INTERP_MI)
     || current_interp_named_p (INTERP_MI1)
*************** captured_mi_execute_command (struct ui_o
*** 1186,1192 ****
    return;
  }
 
-
  void
  mi_execute_command (char *cmd, int from_tty)
  {
--- 1241,1246 ----
*************** mi_execute_cli_command (const char *cmd,
*** 1331,1339 ****
        else
  run = xstrdup (cmd);
        if (mi_debug_p)
! /* FIXME: gdb_???? */
! fprintf_unfiltered (gdb_stdout, "cli=%s run=%s\n",
!    cmd, run);
        old_cleanups = make_cleanup (xfree, run);
        execute_command ( /*ui */ run, 0 /*from_tty */ );
        do_cleanups (old_cleanups);
--- 1385,1397 ----
        else
  run = xstrdup (cmd);
        if (mi_debug_p)
! {
!  fprintf_unfiltered (gdb_stdlog, "  CLI=%s", cmd);
!  if (args_p)
!    fprintf_unfiltered (gdb_stdlog, ", args='%s'", args);
!  fprintf_unfiltered (gdb_stdlog, "\n");
!  gdb_flush (gdb_stdlog);
! }
        old_cleanups = make_cleanup (xfree, run);
        execute_command ( /*ui */ run, 0 /*from_tty */ );
        do_cleanups (old_cleanups);
*************** mi_setup_architecture_data (void)
*** 1513,1523 ****
--- 1571,1598 ----
    memset (old_regs, 0, (NUM_REGS + NUM_PSEUDO_REGS) *
MAX_REGISTER_SIZE + 1);
  }
 
+ static void
+ show_mi_debug (struct ui_file *file, int from_tty,
+       struct cmd_list_element *c, const char *value)
+ {
+   fprintf_filtered (file, _("Debugging of mi protocol is %s.\n"),
+    value);
+ }
+
  void
  _initialize_mi_main (void)
  {
    DEPRECATED_REGISTER_GDBARCH_SWAP (old_regs);
    deprecated_register_gdbarch_swap (NULL, 0,
mi_setup_architecture_data);
+
+   add_setshow_zinteger_cmd ("mi", no_class, &mi_debug_p, _("\
+ Set debugging of mi protocol."), _("\
+ Show debugging of mi protocol."), _("\
+ When enabled, each message sent or received via the mi protocol\n\
+ is displayed."),
+    NULL,
+    show_mi_debug,
+    &setdebuglist, &showdebuglist);
  }
 
  static void

Reply | Threaded
Open this post in threaded view
|

Re: [RFA] set debug mi

Nick Roberts
 > Anybody think this is useful?

Maybe.  I'll take a look.  Have you used it?  Would it be better to register
it as an MI command so that the user doesn't inadvertantly turn it on?  I guess
that the output would confuse any front end.

 > 2007-04-11  Michael Snyder  <[hidden email]>
 >
 > * mi/mi-main.c (print_mi_command, print_mi_status): New functions.
 > (captured_mi_execute_command): Call those if mi_debug_p is true.
 > (mi_execute_cli_command): Make debugging output more concise.
 > (show_mi_debug): New function.
 > (_initialize_mi_main): Add "set/show debug mi" command.

--
Nick                                           http://www.inet.net.nz/~nickrob
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] set debug mi

Jason Molenda
In reply to this post by Michael Snyder-5

On Apr 11, 2007, at 4:50 PM, Michael Snyder wrote:

> Anybody think this is useful?

We do something similar at Apple but we have our front-end program  
deal with it.  The UI has a preference to save the mi log to a file;  
it saves all communication between gdb and the FE to that file.  It's  
invaluable for debugging bug reports - it's invariably the first thing  
we ask for when someone reports a bug against our debugger.  Besides  
pointing the finger at either gdb or the front-end it has the benefit  
of showing exactly what commands were sent to the debugger, instead of  
relying on the user's memory of the same.

I think the approach of having all I/O between the debugger and the FE  
saved is superior but having something like this built in to gdb could  
be helpful for people who can't do that easily in the FE.

J
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] set debug mi

Michael Snyder-5
On Wed, 2007-04-11 at 17:42 -0700, Jason Molenda wrote:

> On Apr 11, 2007, at 4:50 PM, Michael Snyder wrote:
>
> > Anybody think this is useful?
>
> We do something similar at Apple but we have our front-end program  
> deal with it.  The UI has a preference to save the mi log to a file;  
> it saves all communication between gdb and the FE to that file.  It's  
> invaluable for debugging bug reports - it's invariably the first thing  
> we ask for when someone reports a bug against our debugger.  Besides  
> pointing the finger at either gdb or the front-end it has the benefit  
> of showing exactly what commands were sent to the debugger, instead of  
> relying on the user's memory of the same.
>
> I think the approach of having all I/O between the debugger and the FE  
> saved is superior but having something like this built in to gdb could  
> be helpful for people who can't do that easily in the FE.

Eclipse also has a similar option.  I just thought it might be
handy to have the facility on the gdb end as well.  By obvious
analogy with "debug remote".




Reply | Threaded
Open this post in threaded view
|

Re: [RFA] set debug mi

Michael Snyder-5
In reply to this post by Nick Roberts
On Thu, 2007-04-12 at 12:28 +1200, Nick Roberts wrote:
>  > Anybody think this is useful?
>
> Maybe.  I'll take a look.  Have you used it?  Would it be better to register
> it as an MI command so that the user doesn't inadvertantly turn it on?  I guess
> that the output would confuse any front end.

So far I've used it only in the process of implementing it,
but I implemented it because I plan to use it.

As far as inadvertant activation etc., I look at it as
analogous to the "set debug remote" command.  Perhaps both
should be made "maintainer" commands.


Reply | Threaded
Open this post in threaded view
|

Re: [RFA] set debug mi

Vladimir Prus
In reply to this post by Michael Snyder-5
Michael Snyder wrote:

> On Wed, 2007-04-11 at 17:42 -0700, Jason Molenda wrote:
>> On Apr 11, 2007, at 4:50 PM, Michael Snyder wrote:
>>
>> > Anybody think this is useful?
>>
>> We do something similar at Apple but we have our front-end program
>> deal with it.  The UI has a preference to save the mi log to a file;
>> it saves all communication between gdb and the FE to that file.  It's
>> invaluable for debugging bug reports - it's invariably the first thing
>> we ask for when someone reports a bug against our debugger.  Besides
>> pointing the finger at either gdb or the front-end it has the benefit
>> of showing exactly what commands were sent to the debugger, instead of
>> relying on the user's memory of the same.
>>
>> I think the approach of having all I/O between the debugger and the FE
>> saved is superior but having something like this built in to gdb could
>> be helpful for people who can't do that easily in the FE.
>
> Eclipse also has a similar option.  I just thought it might be
> handy to have the facility on the gdb end as well.  By obvious
> analogy with "debug remote".

And KDevelop too. But I think this is better to be done in frontend. Frontend
would probably want to have logs of all debugger interaction shown to the user,
including CLI commands, so having a log file with just MI commands somewhere
won't help.

- Volodya




Reply | Threaded
Open this post in threaded view
|

Re: [RFA] set debug mi

Daniel Jacobowitz-2
In reply to this post by Michael Snyder-5
On Wed, Apr 11, 2007 at 04:50:57PM -0700, Michael Snyder wrote:
> Anybody think this is useful?
>
> 2007-04-11  Michael Snyder  <[hidden email]>
>
> * mi/mi-main.c (print_mi_command, print_mi_status): New functions.
> (captured_mi_execute_command): Call those if mi_debug_p is true.
> (mi_execute_cli_command): Make debugging output more concise.
> (show_mi_debug): New function.
> (_initialize_mi_main): Add "set/show debug mi" command.

I do.  It doesn't replace the FE log, which is what I'd always want
for customer problems, but it could be otherwise useful.

Needs a manual entry.

--
Daniel Jacobowitz
CodeSourcery