diff options
author | Andrew Burgess <aburgess@redhat.com> | 2024-08-07 14:51:06 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2024-08-20 15:44:51 +0100 |
commit | 40a1603112d2b1d330e11792b5506457d5584648 (patch) | |
tree | fda221193c4d990952a525b2d71a657bf914377d /ld/testsuite/ld-aarch64/ifunc-4.d | |
parent | be14b683af735071f5b35b643620973e0588ad98 (diff) | |
download | gdb-master.zip gdb-master.tar.gz gdb-master.tar.bz2 |
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>
Diffstat (limited to 'ld/testsuite/ld-aarch64/ifunc-4.d')
0 files changed, 0 insertions, 0 deletions