gdb: restore warning when core file and executable don't match

Consider the following GDB session:

  (gdb) file /path/to/program
  (gdb) core /path/to/corefile
  warning: core file may not match specified executable file.
  ... etc ...
  (gdb)

Notice the warning.  GDB produces this warning when one of the
following conditions is true:

  + The build-id for the core file doesn't match the build-id of the
    executable, or

  + The filename of the executable doesn't match the partial filename
    stored in the PRPSINFO note from the core file.

Unfortunately, this warning was broken by the following two commits:

  commit c97e57bc9d2e081b7c842742933b7262f1d7ce39
  Date:   Wed Oct 8 11:18:07 2025 +0100

      gdb: move core file bfd from program_space into core_target

  commit 84f8be0d9c8ce30bf56eb9e14ce6fe012125fa53
  Date:   Wed Sep 10 11:04:45 2025 +0100

      gdb: remove program_space::core_bfd member function

These commits changed how the validate_files function (in corefile.c),
which is where the warning is emitted, find the core file BFD object.
Prior to the above commits, the core file BFD was stored in the
program_space, and was set by the time validate_files was called.

After the above commits the core file BFD is stored in the inferior's
core_target, and can only be accessed if the core_target has been
pushed onto the inferior's target stack.

Unfortunately, validate_files is called just before core_target is
pushed.  As a result, in validate_files it appears as if there is no
core file loaded, and so no validation is performed.

This commit fixes that by moving the call to validate_files to after
the core_target is pushed.  The warning is now restored.

I was surprised that this wasn't caught in testing.  I was sure we had
a test for that warning.  But, when I look now, I cannot find any such
test, so this commit adds one.

While I'm adding the test, validate_files also has a warning that it
can emit if the core file is older than the executable.  I've made
sure that the test covers this warning too.

Approved-By: Tom Tromey <tom@tromey.com>

0 files changed, 0 insertions, 0 deletions