diff options
author | Andrew Burgess <aburgess@redhat.com> | 2024-09-13 11:16:51 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2024-09-30 11:22:11 +0100 |
commit | 9dedc2ac713d23609e4c41068fd5efa175217945 (patch) | |
tree | 86a580fe3eb6f195f8baa846835e1ecd08fd4122 /ld/scripttempl/elf32crx.sc | |
parent | 65133b6a081278b0723c13727feb721fdaaf906c (diff) | |
download | binutils-9dedc2ac713d23609e4c41068fd5efa175217945.zip binutils-9dedc2ac713d23609e4c41068fd5efa175217945.tar.gz binutils-9dedc2ac713d23609e4c41068fd5efa175217945.tar.bz2 |
gdb: fix for completing a second filename for a command
After the recent filename completion changes I noticed that the
following didn't work as expected:
(gdb) file "/path/to/some/file" /path/to/so<TAB>
Now, I know that the 'file' command doesn't actually take multiple
filenames, but currently (and this was true before the recent filename
completion changes too) the completion function doesn't know that the
command only expects a single filename, and should complete any number
of filenames. And indeed, this works:
(gdb) file "/path/to/some/file" "/path/to/so<TAB>
In this case I quoted the second path, and now GDB is happy to offer
completions.
It turns out that the problem in the first case is an off-by-one bug
in gdb_completer_file_name_char_is_quoted. This function tells GDB if
a character within the line being completed is escaped or not. An
escaped character cannot be a word separator.
The algorithm in gdb_completer_file_name_char_is_quoted is to scan
forward through the line keeping track of whether we are inside double
or single quotes, or if a character follows a backslash. When we find
an opening quote we skip forward to the closing quote and then check
to see if we skipped over the character we are looking for, if we did
then the character is within the quoted string.
The problem is that this "is character inside quoted string" check
used '>=' instead if '>'. As a consequence a character immediately
after a quoted string would be thought of as inside the quoted string.
In our first example this means that the single white space character
after the quoted string was thought to be quoted, and was not
considered a word breaking character. As such, GDB would not try to
complete the second path. And indeed, if we tried this:
(gdb) file "/path/to/some/file" /path/to/so<TAB>
That is, place multiple spaces after the first path, then GDB would
consider the first space as quoted, but the second space is NOT
quoted, and would be a word break. Now GDB does complete the second
path.
By changing '>=' to '>' in gdb_completer_file_name_char_is_quoted this
bug is resolved, now the original example works and GDB will correctly
complete the second path.
For testing I've factored out the core of one testing proc, and I now
run those tests multiple times, once with no initial path, once with
an initial path in double quotes, once with an initial path in
single quotes, and finally, with an unquoted initial path.
Reviewed-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'ld/scripttempl/elf32crx.sc')
0 files changed, 0 insertions, 0 deletions