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.

0 files changed, 0 insertions, 0 deletions