aboutsummaryrefslogtreecommitdiff
path: root/ld/scripttempl/elf32crx.sc
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2024-09-13 11:16:51 +0100
committerAndrew Burgess <aburgess@redhat.com>2024-09-30 11:22:11 +0100
commit9dedc2ac713d23609e4c41068fd5efa175217945 (patch)
tree86a580fe3eb6f195f8baa846835e1ecd08fd4122 /ld/scripttempl/elf32crx.sc
parent65133b6a081278b0723c13727feb721fdaaf906c (diff)
downloadbinutils-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