aboutsummaryrefslogtreecommitdiff
path: root/gdb/cli
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2021-12-07 22:26:05 +0000
committerAndrew Burgess <aburgess@redhat.com>2022-02-02 16:27:36 +0000
commit82d0a72cdc9ca6cd37a8987e2bcd2eb707c51149 (patch)
tree871b135651665b27e60d77fd25022ce98b6df31b /gdb/cli
parent3c5fcec6dccb0e598d1e64640e55d50ed3ddedb6 (diff)
downloadgdb-82d0a72cdc9ca6cd37a8987e2bcd2eb707c51149.zip
gdb-82d0a72cdc9ca6cd37a8987e2bcd2eb707c51149.tar.gz
gdb-82d0a72cdc9ca6cd37a8987e2bcd2eb707c51149.tar.bz2
gdb: handle calls to edit command passing only a linespec condition
While working on the previous commit to fix PR cli/28665, I noticed that the 'edit' command would suffer from the same problem. That is, something like: (gdb) edit task 123 would cause GDB to break. For a full explanation of what's going on here, see the commit message for the previous commit. As with the previous commit, this issue can be prevented by detecting, and throwing, a junk at the end of the line error earlier, before calling decode_line_1. So, that's what this commit does. I've also added some tests for this issue. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665
Diffstat (limited to 'gdb/cli')
-rw-r--r--gdb/cli/cli-cmds.c7
1 files changed, 4 insertions, 3 deletions
diff --git a/gdb/cli/cli-cmds.c b/gdb/cli/cli-cmds.c
index 648005f..1d14b8e 100644
--- a/gdb/cli/cli-cmds.c
+++ b/gdb/cli/cli-cmds.c
@@ -968,6 +968,10 @@ edit_command (const char *arg, int from_tty)
arg1 = arg;
event_location_up location = string_to_event_location (&arg1,
current_language);
+
+ if (*arg1)
+ error (_("Junk at end of line specification."));
+
std::vector<symtab_and_line> sals = decode_line_1 (location.get (),
DECODE_LINE_LIST_MODE,
NULL, NULL, 0);
@@ -987,9 +991,6 @@ edit_command (const char *arg, int from_tty)
sal = sals[0];
- if (*arg1)
- error (_("Junk at end of line specification."));
-
/* If line was specified by address, first print exactly which
line, and which file. In this case, sal.symtab == 0 means
address is outside of all known source files, not that user