aboutsummaryrefslogtreecommitdiff
path: root/gdb/main.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2024-10-26 16:15:27 +0100
committerAndrew Burgess <aburgess@redhat.com>2024-12-09 11:01:00 +0000
commitd9df3857da0cef29ed9c0ef75f90700c5f392986 (patch)
treeacfedb801859bced1eca5bd14dac3df1b51b9150 /gdb/main.c
parentcced05faea3a51115a4203827e778057607372cc (diff)
downloadbinutils-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.c17
1 files changed, 10 insertions, 7 deletions
diff --git a/gdb/main.c b/gdb/main.c
index 4370e95..14337fb 100644
--- a/gdb/main.c
+++ b/gdb/main.c
@@ -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);
}
}