diff options
author | Andrew Burgess <aburgess@redhat.com> | 2024-10-26 16:15:27 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2024-12-09 11:01:00 +0000 |
commit | d9df3857da0cef29ed9c0ef75f90700c5f392986 (patch) | |
tree | acfedb801859bced1eca5bd14dac3df1b51b9150 /gdb/main.c | |
parent | cced05faea3a51115a4203827e778057607372cc (diff) | |
download | binutils-d9df3857da0cef29ed9c0ef75f90700c5f392986.zip binutils-d9df3857da0cef29ed9c0ef75f90700c5f392986.tar.gz binutils-d9df3857da0cef29ed9c0ef75f90700c5f392986.tar.bz2 |
gdb: allow core file containing special characters on the command line
After the commit:
commit 03ad29c86c232484f9090582bbe6f221bc87c323
Date: Wed Jun 19 11:14:08 2024 +0100
gdb: 'target ...' commands now expect quoted/escaped filenames
it was no longer possible to pass GDB the name of a core file
containing any special characters (white space or quote characters) on
the command line. For example:
$ gdb -c /tmp/core\ file.core
Junk after filename "/tmp/core": file.core
(gdb)
The problem is that the above commit changed the 'target core' command
to expect quoted filenames, so before the above commit a user could
write:
(gdb) target core /tmp/core file.core
[New LWP 2345783]
Core was generated by `./mkcore'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000401111 in ?? ()
(gdb)
But after the above commit the user must write:
(gdb) target core /tmp/core\ file.core
or
(gdb) target core "/tmp/core file.core"
This is part of a move to make GDB's filename argument handling
consistent.
Anyway, the problem with the '-c' command line flag is that it
forwards the filename unmodified through to the 'core-file' command,
which in turn forwards to the 'target core' command.
So when the user, at a shell writes:
$ gdb -c "core file.core"
this arrives in GDB as the unquoted string 'core file.core' (without
the single quotes). GDB then forwards this to the 'core-file'
command as if the user had written this at a GDB prompt:
(gdb) core-file core file.core
Which then fails to parse due to the unquoted white space between
'core' and 'file.core'.
The solution I propose is to escape any special characters in the core
file name passed from the command line before calling 'core-file'
command from main.c.
I've updated the corefile.exp test to include a test for passing a
core file containing a white space character. While I was at it I've
modernised the part of corefile.exp that I was touching.
Diffstat (limited to 'gdb/main.c')
-rw-r--r-- | gdb/main.c | 17 |
1 files changed, 10 insertions, 7 deletions
@@ -1235,7 +1235,8 @@ captured_main_1 (struct captured_main_args *context) if (corearg != NULL) { - ret = catch_command_errors (core_file_command, corearg, + ret = catch_command_errors (core_file_command, + make_quoted_string (corearg).c_str (), !batch_flag); } else if (pidarg != NULL) @@ -1253,16 +1254,18 @@ captured_main_1 (struct captured_main_args *context) ret = catch_command_errors (attach_command, pid_or_core_arg, !batch_flag); if (ret == 0) - ret = catch_command_errors (core_file_command, - pid_or_core_arg, - !batch_flag); + ret = catch_command_errors + (core_file_command, + make_quoted_string (pid_or_core_arg).c_str (), + !batch_flag); } else { /* Can't be a pid, better be a corefile. */ - ret = catch_command_errors (core_file_command, - pid_or_core_arg, - !batch_flag); + ret = catch_command_errors + (core_file_command, + make_quoted_string (pid_or_core_arg).c_str (), + !batch_flag); } } |