aboutsummaryrefslogtreecommitdiff
path: root/gdb
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2024-05-04 10:41:09 +0200
committerTom de Vries <tdevries@suse.de>2024-05-04 10:41:09 +0200
commita0a6e110198c4f7fb4b5baa1f8d158ebf225f7e2 (patch)
treec9ee213bf0e277316b75b38981878dd731c63033 /gdb
parent007a7cb675ff2aa2a5f22fdcacf17553ee4ae427 (diff)
downloadgdb-a0a6e110198c4f7fb4b5baa1f8d158ebf225f7e2.zip
gdb-a0a6e110198c4f7fb4b5baa1f8d158ebf225f7e2.tar.gz
gdb-a0a6e110198c4f7fb4b5baa1f8d158ebf225f7e2.tar.bz2
[gdb/testsuite] Move gpu-parallel.lock to cache dir
The lock directory returned by lock_dir is currently $objdir. It seems possible to leave a stale lock file that blocks progress in a following run. Fix this by using a directory that is guaranteed to be initially empty when using GDB_PARALLEL, like temp or cache. In gdb/testsuite/README I found: ... cache in particular is used to share data across invocations of runtest ... which seems appropriate, so let's use cache for this. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb')
-rw-r--r--gdb/testsuite/lib/gdb-utils.exp2
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/testsuite/lib/gdb-utils.exp b/gdb/testsuite/lib/gdb-utils.exp
index c0b96d3..1f30d80 100644
--- a/gdb/testsuite/lib/gdb-utils.exp
+++ b/gdb/testsuite/lib/gdb-utils.exp
@@ -180,7 +180,7 @@ proc lock_file_release {info} {
# Return directory where we keep lock files.
proc lock_dir {} {
- return $objdir
+ return [make_gdb_parallel_path cache]
}
# Run body under lock LOCK_FILE.