gdb/testsuite: track nested caching proc calls

gdb/testsuite: track nested caching proc calls

It was pointed out in this email:

  https://inbox.sourceware.org/gdb-patches/97973506-79f4-4216-9c0b-57401b3933f5@arm.com

that this commit:

  commit 0726729d344fecf98f8d138e688e77201cc3cece
  Date:   Mon Jun 3 13:56:54 2024 +0100

      gdb/testsuite: track if a caching proc calls gdb_exit or not

had broken some AArch64 tests.

What is going on is that there are two caching procs:

  allow_aarch64_sme_tests
  aarch64_initialize_sme_information

the allow_aarch64_sme_tests proc makes a call to
aarch64_initialize_sme_information, but
aarch64_initialize_sme_information is also called from other
non-caching procs, like aarch64_supports_sme_svl.

Both of the caching procs mentioned above compile and run a helper
program, and both of them call gdb_exit.

After the above commit, the first call to any caching proc, the body
of which calls gdb_exit, will result in a gdb_exit call even if the
body is not executed and the result is fetched from the cache.

What was observed is that in the first test script
allow_aarch64_sme_tests is called, the body of this caching proc is
run which calls gdb_exit.  Then allow_aarch64_sme_tests calls
aarch64_initialize_sme_information, the body of which is run and
gdb_exit is called again.  The results from both procs are added to
the cache.

In the next test script allow_aarch64_sme_tests is called.  This
results in a cache hit, but gdb_exit is also called as this is the
first call in this second test script.

Later in the test script aarch64_supports_sme_svl is called which
calls aarch64_initialize_sme_information.  As this is the first call
to aarch64_initialize_sme_information in this second test
script (remember the body of allow_aarch64_sme_tests was never run)
then gdb_exit is called.  This call to gdb_exit is new after the above
commit and is unexpected.

I think the idea behind the above commit is still sound.  If the call
to allow_aarch64_sme_tests was removed from the second test script
then we would want the extra gdb_exit call as this would expose a real
bug in the test.  The problem is that after the above commit the
nested nature of the caching proc calls becomes important: a call to
allow_aarch64_sme_tests should mean that we've also called
aarch64_initialize_sme_information, and that relationship isn't
currently captured.

So in this commit I'm adding another field to the global
gdb_data_cache (in lib/cache.exp).  This new field is 'also_called'.
For every caching proc we populate this field with a list of names,
these are the names of any nested caching procs that are called when
the body of a caching proc is executed.

Now when we get a cache hit in gdb_data_cache we mark every proc in
the 'also_called' list as having been called.  This means that further
calls to these procs will no longer trigger a gdb_exit call.

Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>