public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb] gdb/testsuite: Fix set_unbuffered_mode.o handling in parallel mode
@ 2024-03-25 20:06 Pedro Alves
0 siblings, 0 replies; only message in thread
From: Pedro Alves @ 2024-03-25 20:06 UTC (permalink / raw)
To: gdb-cvs
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=02d02fc7924992ddd98073b95810b957efdc421a
commit 02d02fc7924992ddd98073b95810b957efdc421a
Author: Pedro Alves <pedro@palves.net>
Date: Fri Mar 22 19:38:39 2024 +0000
gdb/testsuite: Fix set_unbuffered_mode.o handling in parallel mode
Cygwin/MinGW testing links in a set_unbuffered_mode.o object to all
test programs. When running the testsuite in parallel mode, on
Cygwin, I noticed errors like:
ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot open '..../build/set_unbuffered_mode.o' for reading: No such file or directory
...
ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot stat '..../build/set_unbuffered_mode.o': No such file or directory
...
ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: skipping file '..../build/set_unbuffered_mode.o', as it was replaced while being copied
(Absolute paths elided above.)
The problem is that gdb_compile's unbuffered_mode_obj cache isn't
parallel safe. This is fixed in this commit.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I67a289473c14ce0603d4b0beb755b124588f18d2
Diff:
---
gdb/testsuite/lib/gdb.exp | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 606a393271f..d48ea37c0cc 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -5569,10 +5569,20 @@ proc gdb_compile {source dest type options} {
# which is time consuming, especially if we're remote
# host testing.
#
+ # Note the special care for GDB_PARALLEL. In that
+ # scenario, multiple expect instances will potentially try
+ # to compile the object file at the same time. The result
+ # should be identical for every one of them, so we just
+ # need to make sure that the final objfile is written to
+ # atomically.
+
if { $gdb_saved_set_unbuffered_mode_obj == "" } {
verbose "compiling gdb_saved_set_unbuffered_obj"
set unbuf_src ${srcdir}/lib/set_unbuffered_mode.c
- set unbuf_obj ${objdir}/set_unbuffered_mode.o
+ # This gives us a per-expect-instance unique filename,
+ # which is important for GDB_PARALLEL. See comments
+ # above.
+ set unbuf_obj [standard_temp_file set_unbuffered_mode.o]
set result [gdb_compile "${unbuf_src}" "${unbuf_obj}" object {nowarnings}]
if { $result != "" } {
@@ -5585,7 +5595,14 @@ proc gdb_compile {source dest type options} {
}
# Link a copy of the output object, because the
# original may be automatically deleted.
- remote_download host $unbuf_obj $gdb_saved_set_unbuffered_mode_obj
+ if {[info exists ::GDB_PARALLEL]} {
+ # Make sure to write the .o file atomically.
+ # (Note GDB_PARALLEL mode does not support remote
+ # host testing.)
+ file rename -force -- $unbuf_obj $gdb_saved_set_unbuffered_mode_obj
+ } else {
+ remote_download host $unbuf_obj $gdb_saved_set_unbuffered_mode_obj
+ }
} else {
verbose "gdb_saved_set_unbuffered_obj already compiled"
}
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2024-03-25 20:06 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-25 20:06 [binutils-gdb] gdb/testsuite: Fix set_unbuffered_mode.o handling in parallel mode Pedro Alves
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).