aboutsummaryrefslogtreecommitdiff
path: root/gdb/cli
diff options
context:
space:
mode:
authorGareth Rees <grees@undo.io>2020-09-26 11:01:45 -0700
committerJoel Brobecker <brobecker@adacore.com>2020-09-26 11:01:45 -0700
commit8f9929bb97dc0f0fdf60269ac8c9a7d50746646f (patch)
tree8081c9fad347a16b20255ca2c32499914db880b1 /gdb/cli
parent63e5eea234c2bd2c7ce7dc921c71b22bc4fd0d6b (diff)
downloadgdb-8f9929bb97dc0f0fdf60269ac8c9a7d50746646f.zip
gdb-8f9929bb97dc0f0fdf60269ac8c9a7d50746646f.tar.gz
gdb-8f9929bb97dc0f0fdf60269ac8c9a7d50746646f.tar.bz2
gdb: Fix from_tty argument to gdb.execute in Python.
Prior to commit 56bcdbea2b, the from_tty keyword argument to the Python function gdb.execute controlled whether the command took input from the terminal. When from_tty=True, "starti" and similar commands prompted the user: (gdb) python gdb.execute("starti", from_tty=True) The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /bin/true Program stopped. When from_tty=False, these commands did not prompt the user, and "yes" was assumed: (gdb) python gdb.execute("starti", from_tty=False) Program stopped. However, after commit 56bcdbea2b, the from_tty keyword argument no longer had this effect. For example, as of commit 7ade7fba75: (gdb) python gdb.execute("starti", from_tty=True) The program being debugged has been started already. Start it from the beginning? (y or n) [answered Y; input not from terminal] Starting program: /bin/true Program stopped. Note the "[answered Y; input not from terminal]" in the output even though from_tty=True was requested. Looking at commit 56bcdbea2b, it seems that the behaviour of the from_tty argument was changed accidentally. The commit message said: Let gdb.execute handle multi-line commands This changes the Python API so that gdb.execute can now handle multi-line commands, like "commands" or "define". and there was no mention of changing the effect of the from_tty argument. It looks as though the code for setting the instream to nullptr was accidentally moved from execute_user_command() to execute_control_commands() along with the other scoped restores. Accordingly, the simplest way to fix this is to partially reverse commit 56bcdbea2b by moving the code for setting the instream to nullptr back to execute_user_command() where it was to begin with. Additionally, add a test case to reduce the risk of similar breakage in future. gdb/ChangeLog: PR python/26586 * cli/cli-script.c (execute_control_commands): don't set instream to nullptr here as this breaks the from_tty argument to gdb.execute in Python. (execute_user_command): set instream to nullptr here instead. gdb/testsuite/ChangeLog: PR python/26586 * gdb.python/python.exp: add test cases for the from_tty argument to gdb.execute.
Diffstat (limited to 'gdb/cli')
-rw-r--r--gdb/cli/cli-script.c9
1 files changed, 5 insertions, 4 deletions
diff --git a/gdb/cli/cli-script.c b/gdb/cli/cli-script.c
index da4a410..f8ac610 100644
--- a/gdb/cli/cli-script.c
+++ b/gdb/cli/cli-script.c
@@ -392,10 +392,6 @@ execute_cmd_post_hook (struct cmd_list_element *c)
void
execute_control_commands (struct command_line *cmdlines, int from_tty)
{
- /* Set the instream to 0, indicating execution of a
- user-defined function. */
- scoped_restore restore_instream
- = make_scoped_restore (&current_ui->instream, nullptr);
scoped_restore save_async = make_scoped_restore (&current_ui->async, 0);
scoped_restore save_nesting
= make_scoped_restore (&command_nest_depth, command_nest_depth + 1);
@@ -464,6 +460,11 @@ execute_user_command (struct cmd_list_element *c, const char *args)
if (user_args_stack.size () > max_user_call_depth)
error (_("Max user call depth exceeded -- command aborted."));
+ /* Set the instream to nullptr, indicating execution of a
+ user-defined function. */
+ scoped_restore restore_instream
+ = make_scoped_restore (&current_ui->instream, nullptr);
+
execute_control_commands (cmdlines, 0);
}