Breakpoint commands in MI mode and "backtrace"

Breakpoint commands in MI mode and "backtrace"

[Eli Zaretskii]

There seems to be a problem with execution of "bt" as part of
breakpoint commands in MI mode: the output of "bt" is not shown.

What I did was invoke GDB as "gdb -i=mi PROGRAM", then set a
breakpoint or a watchpoint in that program, and defined the following
as its breakpoint commands:

  bt
  end

When the breakpoint triggers, I don't see the backtrace.

I tried other commands, like "up" and "print SOME-VARIABLE", and they
do seem to be executed and the output shown.  So why doesn't that
happen with "backtrace"?  Is it a bug or am I missing something?

(FWIW, I also tried using -break-commands, with a similar result: the
backtrace is not shown when the breakpoint triggers.)

This problem prevents "bt" from being useful in breakpoint commands
when running with the Emacs GDB front-end, which uses MI.

Thanks in advance for any pointers.

Re: Breakpoint commands in MI mode and "backtrace"

[Eli Zaretskii]

> From: Simon Marchi <simark@simark.ca>
> Date: Sun, 8 Oct 2017 13:51:39 -0400
> 
> It seems like even though we are executing CLI commands, the current interpreter
> and uiout are the MI ones.  I'm always confused by all these data structures, but
> I managed to hack it to work with this:
> 
> diff --git a/gdb/cli/cli-script.c b/gdb/cli/cli-script.c
> index 0a93e8b54f..bc8e1047c5 100644
> --- a/gdb/cli/cli-script.c
> +++ b/gdb/cli/cli-script.c
> @@ -482,7 +482,10 @@ execute_control_command (struct command_line *cmd)
>        {
>  	/* A simple command, execute it and return.  */
>  	std::string new_line = insert_user_defined_cmd_args (cmd->line);
> -	execute_command (&new_line[0], 0);
> +
> +	scoped_restore_interp restorer (INTERP_CONSOLE);
> +	current_interpreter ()->exec (&new_line[0]);
> +
>  	ret = cmd->control_type;
>  	break;
>        }
> 
> Does that work for you?  It might not be the right solution, but it's a start.

This doesn't compile when applied to GDB 8.0 code.  Can the same be
done with the scoped_restore class instead?

In any case, there are more instances of calls to execute_command in
that function, and I guess they all need to be changed like that?

Thanks.

Re: Breakpoint commands in MI mode and "backtrace"

[Simon Marchi]

On 2017-10-08 02:26 PM, Eli Zaretskii wrote:
> This doesn't compile when applied to GDB 8.0 code.  Can the same be
> done with the scoped_restore class instead?

I don't know, maybe.  But here's the equivalent version with the corresponding
cleanup, that applies on the 8.0 branch:

diff --git a/gdb/cli/cli-script.c b/gdb/cli/cli-script.c
index f1db954a69..34ae4966de 100644
--- a/gdb/cli/cli-script.c
+++ b/gdb/cli/cli-script.c
@@ -472,6 +472,8 @@ print_command_trace (const char *cmd)
   printf_filtered ("%s\n", cmd);
 }

+static void restore_interp (void *arg);
+
 enum command_control_type
 execute_control_command (struct command_line *cmd)
 {
@@ -491,8 +493,14 @@ execute_control_command (struct command_line *cmd)
       {
 	/* A simple command, execute it and return.  */
 	std::string new_line = insert_user_defined_cmd_args (cmd->line);
-	execute_command (&new_line[0], 0);
+
+	struct interp *old_interp = interp_set_temp (INTERP_CONSOLE);
+	struct cleanup *old_chain = make_cleanup (restore_interp, old_interp);
+
+	current_interpreter ()->exec (&new_line[0]);
 	ret = cmd->control_type;
+
+	do_cleanups (old_chain);
 	break;
       }

> In any case, there are more instances of calls to execute_command in
> that function, and I guess they all need to be changed like that?

I don't see any other call.

Simon

Re: Breakpoint commands in MI mode and "backtrace"

[Eli Zaretskii]

> Cc: gdb@sourceware.org
> From: Simon Marchi <simark@simark.ca>
> Date: Sun, 8 Oct 2017 15:24:21 -0400
> 
> But here's the equivalent version with the corresponding cleanup,
> that applies on the 8.0 branch:
> 
> diff --git a/gdb/cli/cli-script.c b/gdb/cli/cli-script.c
> index f1db954a69..34ae4966de 100644
> --- a/gdb/cli/cli-script.c
> +++ b/gdb/cli/cli-script.c
> @@ -472,6 +472,8 @@ print_command_trace (const char *cmd)
>    printf_filtered ("%s\n", cmd);
>  }
> 
> +static void restore_interp (void *arg);
> +
>  enum command_control_type
>  execute_control_command (struct command_line *cmd)
>  {
> @@ -491,8 +493,14 @@ execute_control_command (struct command_line *cmd)
>        {
>  	/* A simple command, execute it and return.  */
>  	std::string new_line = insert_user_defined_cmd_args (cmd->line);
> -	execute_command (&new_line[0], 0);
> +
> +	struct interp *old_interp = interp_set_temp (INTERP_CONSOLE);
> +	struct cleanup *old_chain = make_cleanup (restore_interp, old_interp);
> +
> +	current_interpreter ()->exec (&new_line[0]);
>  	ret = cmd->control_type;
> +
> +	do_cleanups (old_chain);
>  	break;
>        }

Thanks, this works, but it seems to fail hookpost hooks.  The Emacs
.gdbinit file defines a hookpost-backtrace command to produce a
Lisp-level backtrace, and with this change that fails:

  ~"Lisp Backtrace:\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"
  &"Argument to arithmetic operation not a number or boolean.\n"

Whereas without the patch, the C-level backtrace is not shown, but the
Lisp-level backtrace is shown correctly:

  ~"Lisp Backtrace:\n"
  ~"\"redraw-display\""
  ~" (0x82de90)\n"
  ~"\"funcall-interactively\""
  ~" (0x82de88)\n"
  ~"\"call-interactively\""
  ~" (0x82e1e0)\n"
  ~"\"command-execute\""
  ~" (0x82e738)\n"
  ~"\"execute-extended-command\""
  ~" (0x82ee20)\n"
  ~"\"funcall-interactively\""
  ~" (0x82ee18)\n"
  ~"\"call-interactively\""
  ~" (0x82f220)\n"
  ~"\"command-execute\""
  ~" (0x82f748)\n"

> > In any case, there are more instances of calls to execute_command in
> > that function, and I guess they all need to be changed like that?
> 
> I don't see any other call.

You are right, sorry.

Thanks.

Re: Breakpoint commands in MI mode and "backtrace"

[Simon Marchi]

On 2017-10-08 04:02 PM, Eli Zaretskii wrote:
>> Cc: gdb@sourceware.org
>> From: Simon Marchi <simark@simark.ca>
>> Date: Sun, 8 Oct 2017 15:24:21 -0400
>>
>> But here's the equivalent version with the corresponding cleanup,
>> that applies on the 8.0 branch:
>>
>> diff --git a/gdb/cli/cli-script.c b/gdb/cli/cli-script.c
>> index f1db954a69..34ae4966de 100644
>> --- a/gdb/cli/cli-script.c
>> +++ b/gdb/cli/cli-script.c
>> @@ -472,6 +472,8 @@ print_command_trace (const char *cmd)
>>    printf_filtered ("%s\n", cmd);
>>  }
>>
>> +static void restore_interp (void *arg);
>> +
>>  enum command_control_type
>>  execute_control_command (struct command_line *cmd)
>>  {
>> @@ -491,8 +493,14 @@ execute_control_command (struct command_line *cmd)
>>        {
>>  	/* A simple command, execute it and return.  */
>>  	std::string new_line = insert_user_defined_cmd_args (cmd->line);
>> -	execute_command (&new_line[0], 0);
>> +
>> +	struct interp *old_interp = interp_set_temp (INTERP_CONSOLE);
>> +	struct cleanup *old_chain = make_cleanup (restore_interp, old_interp);
>> +
>> +	current_interpreter ()->exec (&new_line[0]);
>>  	ret = cmd->control_type;
>> +
>> +	do_cleanups (old_chain);
>>  	break;
>>        }
> 
> Thanks, this works, but it seems to fail hookpost hooks.  The Emacs
> .gdbinit file defines a hookpost-backtrace command to produce a
> Lisp-level backtrace, and with this change that fails:
> 
>   ~"Lisp Backtrace:\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
>   &"Argument to arithmetic operation not a number or boolean.\n"
> 
> Whereas without the patch, the C-level backtrace is not shown, but the
> Lisp-level backtrace is shown correctly:
> 
>   ~"Lisp Backtrace:\n"
>   ~"\"redraw-display\""
>   ~" (0x82de90)\n"
>   ~"\"funcall-interactively\""
>   ~" (0x82de88)\n"
>   ~"\"call-interactively\""
>   ~" (0x82e1e0)\n"
>   ~"\"command-execute\""
>   ~" (0x82e738)\n"
>   ~"\"execute-extended-command\""
>   ~" (0x82ee20)\n"
>   ~"\"funcall-interactively\""
>   ~" (0x82ee18)\n"
>   ~"\"call-interactively\""
>   ~" (0x82f220)\n"
>   ~"\"command-execute\""
>   ~" (0x82f748)\n"

Hmm, strange.  It is a quite complex function being executed in the hookpost-backtrace.
Do you have any idea what line generates the error?  It would be nice to have a
reproducer without having to build emacs...

Thanks,

Simon

Re: Breakpoint commands in MI mode and "backtrace"

[Eli Zaretskii]

> Cc: gdb@sourceware.org
> From: Simon Marchi <simark@simark.ca>
> Date: Mon, 9 Oct 2017 00:16:28 -0400
> 
> Hmm, strange.  It is a quite complex function being executed in the hookpost-backtrace.
> Do you have any idea what line generates the error?  It would be nice to have a
> reproducer without having to build emacs...

It's this line in xgetsysm:

    set $ptr = ((struct Lisp_Symbol *) ((char *)lispsym + $ptr))

where $ptr is a pointer to a Lisp_Symbol object:

  (gdb) p $ptr
  $2 = (struct Lisp_Symbol *) 0x17c9e38 <dumped_data+267384>

and lispsym is an array:

  (gdb) ptype lispsym
  type = struct {
      struct Lisp_Symbol s;
  } [1298]

Let me know if I can provide more information about this.

Re: Breakpoint commands in MI mode and "backtrace"

[Eli Zaretskii]

> Date: Mon, 09 Oct 2017 10:27:15 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: gdb@sourceware.org
> 
> > Cc: gdb@sourceware.org
> > From: Simon Marchi <simark@simark.ca>
> > Date: Mon, 9 Oct 2017 00:16:28 -0400
> > 
> > Hmm, strange.  It is a quite complex function being executed in the hookpost-backtrace.
> > Do you have any idea what line generates the error?  It would be nice to have a
> > reproducer without having to build emacs...
> 
> It's this line in xgetsysm:
> 
>     set $ptr = ((struct Lisp_Symbol *) ((char *)lispsym + $ptr))
> 
> where $ptr is a pointer to a Lisp_Symbol object:
> 
>   (gdb) p $ptr
>   $2 = (struct Lisp_Symbol *) 0x17c9e38 <dumped_data+267384>
> 
> and lispsym is an array:
> 
>   (gdb) ptype lispsym
>   type = struct {
>       struct Lisp_Symbol s;
>   } [1298]
> 
> Let me know if I can provide more information about this.

Btw, with the patch, I get the same error if I invoke GDB in CLI mode.

Thanks.

Re: Breakpoint commands in MI mode and "backtrace"

[Simon Marchi]

On 2017-10-09 03:52 AM, Eli Zaretskii wrote:
>> Date: Mon, 09 Oct 2017 10:27:15 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> CC: gdb@sourceware.org
>>
>>> Cc: gdb@sourceware.org
>>> From: Simon Marchi <simark@simark.ca>
>>> Date: Mon, 9 Oct 2017 00:16:28 -0400
>>>
>>> Hmm, strange.  It is a quite complex function being executed in the hookpost-backtrace.
>>> Do you have any idea what line generates the error?  It would be nice to have a
>>> reproducer without having to build emacs...
>>
>> It's this line in xgetsysm:
>>
>>     set $ptr = ((struct Lisp_Symbol *) ((char *)lispsym + $ptr))
>>
>> where $ptr is a pointer to a Lisp_Symbol object:
>>
>>   (gdb) p $ptr
>>   $2 = (struct Lisp_Symbol *) 0x17c9e38 <dumped_data+267384>
>>
>> and lispsym is an array:
>>
>>   (gdb) ptype lispsym
>>   type = struct {
>>       struct Lisp_Symbol s;
>>   } [1298]
>>
>> Let me know if I can provide more information about this.
> 
> Btw, with the patch, I get the same error if I invoke GDB in CLI mode.
> 
> Thanks.
> 

It's true that my patch seems to change how exceptions are handled, since
safe_execute_command catches and prints exceptions.  However, that expression
does indeed seem erroenous, and I'm surprised GDB doesn't complain about it
currently.  How can you add a char* and a listp_Symbol*?

Anyhow, can you try this patch here?  It changes the uiout manually instead of
going through safe_execute_command.


diff --git a/gdb/cli/cli-script.c b/gdb/cli/cli-script.c
index f1db954a69..b08954132b 100644
--- a/gdb/cli/cli-script.c
+++ b/gdb/cli/cli-script.c
@@ -472,6 +472,8 @@ print_command_trace (const char *cmd)
   printf_filtered ("%s\n", cmd);
 }

+static void restore_interp (void *arg);
+
 enum command_control_type
 execute_control_command (struct command_line *cmd)
 {
@@ -491,8 +493,17 @@ execute_control_command (struct command_line *cmd)
       {
 	/* A simple command, execute it and return.  */
 	std::string new_line = insert_user_defined_cmd_args (cmd->line);
+
+	struct interp *old_interp = interp_set_temp (INTERP_CONSOLE);
+	struct cleanup *old_chain = make_cleanup (restore_interp, old_interp);
+	scoped_restore save_uiout
+	  = make_scoped_restore (&current_uiout,
+		     current_interpreter ()->interp_ui_out ());
+
 	execute_command (&new_line[0], 0);
 	ret = cmd->control_type;
+
+	do_cleanups (old_chain);
 	break;
       }

Re: Breakpoint commands in MI mode and "backtrace"

[Eli Zaretskii]

> Cc: gdb@sourceware.org
> From: Simon Marchi <simark@simark.ca>
> Date: Mon, 9 Oct 2017 08:02:24 -0400
> 
> It's true that my patch seems to change how exceptions are handled, since
> safe_execute_command catches and prints exceptions.  However, that expression
> does indeed seem erroenous, and I'm surprised GDB doesn't complain about it
> currently.  How can you add a char* and a listp_Symbol*?

Sorry, that's my fault: actually $ptr at that point is just a number,
410072 in my case.  Apologies for confusing you.

> Anyhow, can you try this patch here?  It changes the uiout manually instead of
> going through safe_execute_command.

It works, thanks.  I tried both in CLI mode and in MI mode, and it
works with both.

Re: Breakpoint commands in MI mode and "backtrace"

[Eli Zaretskii]

> Cc: gdb@sourceware.org
> From: Simon Marchi <simark@simark.ca>
> Date: Mon, 9 Oct 2017 08:02:24 -0400
> 
> Anyhow, can you try this patch here?  It changes the uiout manually instead of
> going through safe_execute_command.

Since this worked for me, in GDB 8.0, can something similar be put in
the current master, so the next GDB release will have this bug fixed?

Thanks.

> diff --git a/gdb/cli/cli-script.c b/gdb/cli/cli-script.c
> index f1db954a69..b08954132b 100644
> --- a/gdb/cli/cli-script.c
> +++ b/gdb/cli/cli-script.c
> @@ -472,6 +472,8 @@ print_command_trace (const char *cmd)
>    printf_filtered ("%s\n", cmd);
>  }
> 
> +static void restore_interp (void *arg);
> +
>  enum command_control_type
>  execute_control_command (struct command_line *cmd)
>  {
> @@ -491,8 +493,17 @@ execute_control_command (struct command_line *cmd)
>        {
>  	/* A simple command, execute it and return.  */
>  	std::string new_line = insert_user_defined_cmd_args (cmd->line);
> +
> +	struct interp *old_interp = interp_set_temp (INTERP_CONSOLE);
> +	struct cleanup *old_chain = make_cleanup (restore_interp, old_interp);
> +	scoped_restore save_uiout
> +	  = make_scoped_restore (&current_uiout,
> +		     current_interpreter ()->interp_ui_out ());
> +
>  	execute_command (&new_line[0], 0);
>  	ret = cmd->control_type;
> +
> +	do_cleanups (old_chain);
>  	break;
>        }
> 
> 
> 

Re: Breakpoint commands in MI mode and "backtrace"

[Simon Marchi]

On 2017-10-21 04:26 AM, Eli Zaretskii wrote:
>> Cc: gdb@sourceware.org
>> From: Simon Marchi <simark@simark.ca>
>> Date: Mon, 9 Oct 2017 08:02:24 -0400
>>
>> Anyhow, can you try this patch here?  It changes the uiout manually instead of
>> going through safe_execute_command.
> 
> Since this worked for me, in GDB 8.0, can something similar be put in
> the current master, so the next GDB release will have this bug fixed?
> 
> Thanks.

I'll look into it, but I'll try a slightly different patch.  The one I sent
previously sets and restores the interpreter at every executed command, which
is inefficient.  I'll try to set and restore only once at a higher level in
the call stack.

Simon

Re: Breakpoint commands in MI mode and "backtrace"

[Eli Zaretskii]

> Cc: gdb@sourceware.org, gdb-patches@sourceware.org
> From: Simon Marchi <simark@simark.ca>
> Date: Sat, 21 Oct 2017 10:13:20 -0400
> 
> > Since this worked for me, in GDB 8.0, can something similar be put in
> > the current master, so the next GDB release will have this bug fixed?
> > 
> > Thanks.
> 
> I'll look into it, but I'll try a slightly different patch.  The one I sent
> previously sets and restores the interpreter at every executed command, which
> is inefficient.  I'll try to set and restore only once at a higher level in
> the call stack.

Thank you.