tree e45c6a8c97f16abe8683089311f12d2ac909e9d9
parent 600456716565103241530d7bd429cd9fb6c6258b
author Andrew Burgess <aburgess@redhat.com> 1729803850 +0100
committer Andrew Burgess <aburgess@redhat.com> 1735049724 +0000

gdb/testsuite: make some of the core file / build-id tests harder

We have a few tests that load core files, which depend on GDB not
auto-loading the executable that matches the core file.  One of these
tests (corefile-buildid.exp) exercises GDB's ability to load the
executable via the build-id links in the debug directory, while the
other two tests are just written assuming that GDB hasn't auto-loaded
the executable.

In the next commit, GDB is going to get better at finding the
executable for a core file, and as a consequence these tests could
start to fail if the testsuite is being run using a compiler that adds
build-ids by default, and is on a target (currently only Linux) with
the improved executable auto-loading.

To avoid these test failures, this commit updates some of the tests.

coredump-filter.exp and corefile.exp are updated to unload the
executable should it be auto-loaded.  This means that the following
output from GDB will match the expected patterns.  If the executable
wasn't auto-loaded then the new step to unload is harmless.

The corefile-buildid.exp test needed some more significant changes.
For this test it is important that the executable be moved aside so
that GDB can't locate it, but we do still need the executable around
somewhere, so that the debug directory can link to it.  The point of
the test is that the executable _should_ be auto-loaded, but using the
debug directory, not using GDB's context parsing logic.

While looking at this test I noticed two additional problems, first we
were creating the core file more times than we needed.  We only need
to create one core file for each test binary (total two), while we
previously created one core file for each style of debug info
directory (total four).  The extra core files should be identical, and
were just overwriting each other, harmless, but still pointless work.

The other problem is that after running an earlier test we modified
the test binary in order to run a later test.  This means it's not
possible to manually re-run the first test as the binary for that test
is destroyed.

As part of the rewrite in this commit I've addressed these issues.

This test does change many of the test names, but there should be no
real changes in what is being tested after this commit.  However, when
the next commit is added, and GDB gets better at auto-loading the
executable for a core file, these tests should still be testing what
is expected.