diff mbox series

[5/7,gdb/testsuite] Move gpu-parallel.lock to cache dir

Message ID 20240415155627.22108-5-tdevries@suse.de
State New
Headers
Series [1/7,gdb/testsuite] Factor out proc get_portnum |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gdb_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 success Testing passed

Commit Message

Tom de Vries April 15, 2024, 3:56 p.m. UTC 
  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.
---
 gdb/testsuite/lib/gdb-utils.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff mbox series

Patch

diff --git a/gdb/testsuite/lib/gdb-utils.exp b/gdb/testsuite/lib/gdb-utils.exp
index c0b96d3c2bf..1f30d807ff0 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.