* [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp @ 2023-06-16 11:33 Tom de Vries 2023-06-16 18:38 ` Tom Tromey 0 siblings, 1 reply; 12+ messages in thread From: Tom de Vries @ 2023-06-16 11:33 UTC (permalink / raw) To: gdb-patches Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works fine, but if we run it again with target board unix-m32, we run into: ... gnatlink prog.ali -m32 -g -o prog^M ld: i386:x86-64 architecture of input file `b~prog.o' is incompatible with \ i386 output^M ... This is due to compiling with no-force. The test-case: - first compiles pck.adb into pck.o (without debug info), and - then compiles prog.adb and pck.o into prog (with debug info). Using no-force in the second compilation make sure that pck.adb is not compiled again, with debug info. But it also means it will pick up intermediate files related to prog.adb from a previous compilation. Fix this by removing prog.o and prog.ali before compilation. Tested on x86_64-linux. --- gdb/testsuite/gdb.ada/call-no-debug.exp | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/gdb/testsuite/gdb.ada/call-no-debug.exp b/gdb/testsuite/gdb.ada/call-no-debug.exp index 422b83761d9..df81c87ade2 100644 --- a/gdb/testsuite/gdb.ada/call-no-debug.exp +++ b/gdb/testsuite/gdb.ada/call-no-debug.exp @@ -21,6 +21,11 @@ require allow_ada_tests standard_ada_testfile prog +# Since we use no-force to compile prog, make sure we don't pick up files +# from a previous compilation. +remote_file host delete [standard_output_file prog.o] +remote_file host delete [standard_output_file prog.ali] + # Compile pck without debuginfo but prog with it. if {[gdb_compile_ada $srcdir/$subdir/$testdir/pck.adb \ [standard_output_file pck.o] object {}] != ""} { base-commit: 9fb38608660d25f368b458a17e5f013271da7d4a -- 2.35.3 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-16 11:33 [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp Tom de Vries @ 2023-06-16 18:38 ` Tom Tromey 2023-06-17 10:50 ` Tom de Vries 0 siblings, 1 reply; 12+ messages in thread From: Tom Tromey @ 2023-06-16 18:38 UTC (permalink / raw) To: Tom de Vries via Gdb-patches; +Cc: Tom de Vries >>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes: Tom> Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works Tom> fine, but if we run it again with target board unix-m32, we run into: Thanks for doing this. If gdb's test suite could detect when a new .exp is started, we could make this always work by removing the corresponding standard output directory. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-16 18:38 ` Tom Tromey @ 2023-06-17 10:50 ` Tom de Vries 2023-06-17 20:14 ` Tom Tromey 2023-06-19 14:25 ` Luis Machado 0 siblings, 2 replies; 12+ messages in thread From: Tom de Vries @ 2023-06-17 10:50 UTC (permalink / raw) To: Tom Tromey, Tom de Vries via Gdb-patches [-- Attachment #1: Type: text/plain, Size: 555 bytes --] On 6/16/23 20:38, Tom Tromey wrote: >>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes: > > Tom> Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works > Tom> fine, but if we run it again with target board unix-m32, we run into: > > Thanks for doing this. > > If gdb's test suite could detect when a new .exp is started, we could > make this always work by removing the corresponding standard output directory. Hi, thanks for the suggestion, I've implemented it in gdb_init. WDYT? Thanks, - Tom [-- Attachment #2: 0001-gdb-testsuite-Clean-standard_output_file-dir-in-gdb_.patch --] [-- Type: text/x-patch, Size: 2117 bytes --] From f6b5a812244b824a72f305e74f2853d03d4d3ed1 Mon Sep 17 00:00:00 2001 From: Tom de Vries <tdevries@suse.de> Date: Sat, 17 Jun 2023 12:37:46 +0200 Subject: [PATCH] [gdb/testsuite] Clean standard_output_file dir in gdb_init In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some files at the start of the test-case: ... remote_file host delete [standard_output_file prog.o] remote_file host delete [standard_output_file prog.ali] ... Replace this with cleaning up the entire directory instead, for all test-cases. Tested on x86_64-linux. --- gdb/testsuite/gdb.ada/call-no-debug.exp | 5 ----- gdb/testsuite/lib/gdb.exp | 3 +++ 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/gdb/testsuite/gdb.ada/call-no-debug.exp b/gdb/testsuite/gdb.ada/call-no-debug.exp index df81c87ade2..422b83761d9 100644 --- a/gdb/testsuite/gdb.ada/call-no-debug.exp +++ b/gdb/testsuite/gdb.ada/call-no-debug.exp @@ -21,11 +21,6 @@ require allow_ada_tests standard_ada_testfile prog -# Since we use no-force to compile prog, make sure we don't pick up files -# from a previous compilation. -remote_file host delete [standard_output_file prog.o] -remote_file host delete [standard_output_file prog.ali] - # Compile pck without debuginfo but prog with it. if {[gdb_compile_ada $srcdir/$subdir/$testdir/pck.adb \ [standard_output_file pck.o] object {}] != ""} { diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index f214a6bb54d..741b851b900 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -6420,6 +6420,9 @@ proc default_gdb_init { test_file_name } { set gdb_test_file_name [file rootname [file tail $test_file_name]] + # Clean directory containing the standard output files. + remote_exec build "rm -rf [standard_output_file ""]" + # Make sure that the wrapper is rebuilt # with the appropriate multilib option. if { $gdb_wrapper_target != [current_target_name] } { base-commit: 34a6dcd4422a194a45ae5297ca6d0d56d4c75e97 -- 2.35.3 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-17 10:50 ` Tom de Vries @ 2023-06-17 20:14 ` Tom Tromey 2023-06-19 14:25 ` Luis Machado 1 sibling, 0 replies; 12+ messages in thread From: Tom Tromey @ 2023-06-17 20:14 UTC (permalink / raw) To: Tom de Vries; +Cc: Tom Tromey, Tom de Vries via Gdb-patches Tom> thanks for the suggestion, I've implemented it in gdb_init. WDYT? Looks good to me. Thank you. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-17 10:50 ` Tom de Vries 2023-06-17 20:14 ` Tom Tromey @ 2023-06-19 14:25 ` Luis Machado 2023-06-19 14:26 ` Luis Machado 1 sibling, 1 reply; 12+ messages in thread From: Luis Machado @ 2023-06-19 14:25 UTC (permalink / raw) To: Tom de Vries, Tom Tromey, Tom de Vries via Gdb-patches On 6/17/23 11:50, Tom de Vries via Gdb-patches wrote: > On 6/16/23 20:38, Tom Tromey wrote: >>>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes: >> >> Tom> Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works >> Tom> fine, but if we run it again with target board unix-m32, we run into: >> >> Thanks for doing this. >> >> If gdb's test suite could detect when a new .exp is started, we could >> make this always work by removing the corresponding standard output directory. > > Hi, > > thanks for the suggestion, I've implemented it in gdb_init. WDYT? > > Thanks, > - Tom Would this delete files unrelated to the specific test being executed? I started to see a number of errors in the testsuite where tests executed in parallel can't find gdb.log. For instance: --- ERROR: tcl error sourcing binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp. ERROR: couldn't open "outputs/gdb.arch/aarch64-sve/gdb.log": no such file or directory while executing "log_file -a outputs/gdb.arch/aarch64-sve/gdb.log" ("eval" body line 1) invoked from within "eval log_file $saved_log" (procedure "get_compiler_info" line 51) invoked from within "get_compiler_info $language" (procedure "test_compiler_info" line 4) invoked from within "test_compiler_info "clang-*"" (procedure "gdb_compile" line 41) invoked from within "gdb_compile $src $obj $type $compile_flags" (procedure "gdb_simple_compile" line 44) invoked from within "gdb_simple_compile $name $code $type $compile_flags temp_obj $default_compile_flags" (procedure "gdb_can_simple_compile" line 2) invoked from within "gdb_can_simple_compile aarch32 [join $list \n]" (procedure "gdb_real__is_aarch32_target" line 15) invoked from within "gdb_real__is_aarch32_target" ("uplevel" body line 1) invoked from within "uplevel 2 $real_name" (procedure "gdb_do_cache_wrap" line 3) invoked from within "gdb_do_cache_wrap $real_name {*}$args" (procedure "gdb_do_cache" line 48) invoked from within "gdb_do_cache is_aarch32_target" (procedure "is_aarch32_target" line 1) invoked from within "is_aarch32_target" (procedure "is_aarch64_target" line 6) invoked from within "is_aarch64_target" (procedure "gdb_real__allow_aarch64_sve_tests" line 6) invoked from within "gdb_real__allow_aarch64_sve_tests" ("uplevel" body line 1) invoked from within "uplevel 2 [list $real_name {*}$args]" invoked from within "gdb_do_cache_wrap $real_name {*}$args" (procedure "gdb_do_cache" line 48) invoked from within "gdb_do_cache allow_aarch64_sve_tests" (procedure "allow_aarch64_sve_tests" line 1) invoked from within "allow_aarch64_sve_tests" ("uplevel" body line 1) invoked from within "uplevel 1 $fn" (procedure "require" line 11) invoked from within "require allow_aarch64_sve_tests" (file "binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp" line 18) invoked from within "source binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp" invoked from within "catch "uplevel #0 source $test_file_name"" --- When reverting this patch, I no longer see the problem. Maybe it is deleting more than it should? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-19 14:25 ` Luis Machado @ 2023-06-19 14:26 ` Luis Machado 2023-06-19 17:12 ` Tom de Vries 2023-06-19 17:19 ` Tom Tromey 0 siblings, 2 replies; 12+ messages in thread From: Luis Machado @ 2023-06-19 14:26 UTC (permalink / raw) To: Tom de Vries, Tom Tromey, Tom de Vries via Gdb-patches On 6/19/23 15:25, Luis Machado wrote: > On 6/17/23 11:50, Tom de Vries via Gdb-patches wrote: >> On 6/16/23 20:38, Tom Tromey wrote: >>>>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes: >>> >>> Tom> Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works >>> Tom> fine, but if we run it again with target board unix-m32, we run into: >>> >>> Thanks for doing this. >>> >>> If gdb's test suite could detect when a new .exp is started, we could >>> make this always work by removing the corresponding standard output directory. >> >> Hi, >> >> thanks for the suggestion, I've implemented it in gdb_init. WDYT? >> >> Thanks, >> - Tom > > Would this delete files unrelated to the specific test being executed? I started to see a number > of errors in the testsuite where tests executed in parallel can't find gdb.log. > > For instance: > > --- > > ERROR: tcl error sourcing binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp. > ERROR: couldn't open "outputs/gdb.arch/aarch64-sve/gdb.log": no such file or directory > while executing > "log_file -a outputs/gdb.arch/aarch64-sve/gdb.log" > ("eval" body line 1) > invoked from within > "eval log_file $saved_log" > (procedure "get_compiler_info" line 51) > invoked from within > "get_compiler_info $language" > (procedure "test_compiler_info" line 4) > invoked from within > "test_compiler_info "clang-*"" > (procedure "gdb_compile" line 41) > invoked from within > "gdb_compile $src $obj $type $compile_flags" > (procedure "gdb_simple_compile" line 44) > invoked from within > "gdb_simple_compile $name $code $type $compile_flags temp_obj $default_compile_flags" > (procedure "gdb_can_simple_compile" line 2) > invoked from within > "gdb_can_simple_compile aarch32 [join $list \n]" > (procedure "gdb_real__is_aarch32_target" line 15) > invoked from within > "gdb_real__is_aarch32_target" > ("uplevel" body line 1) > invoked from within > "uplevel 2 $real_name" > (procedure "gdb_do_cache_wrap" line 3) > invoked from within > "gdb_do_cache_wrap $real_name {*}$args" > (procedure "gdb_do_cache" line 48) > invoked from within > "gdb_do_cache is_aarch32_target" > (procedure "is_aarch32_target" line 1) > invoked from within > "is_aarch32_target" > (procedure "is_aarch64_target" line 6) > invoked from within > "is_aarch64_target" > (procedure "gdb_real__allow_aarch64_sve_tests" line 6) > invoked from within > "gdb_real__allow_aarch64_sve_tests" > ("uplevel" body line 1) > invoked from within > "uplevel 2 [list $real_name {*}$args]" > invoked from within > "gdb_do_cache_wrap $real_name {*}$args" > (procedure "gdb_do_cache" line 48) > invoked from within > "gdb_do_cache allow_aarch64_sve_tests" > (procedure "allow_aarch64_sve_tests" line 1) > invoked from within > "allow_aarch64_sve_tests" > ("uplevel" body line 1) > invoked from within > "uplevel 1 $fn" > (procedure "require" line 11) > invoked from within > "require allow_aarch64_sve_tests" > (file "binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp" line 18) > invoked from within > "source binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp" > ("uplevel" body line 1) > invoked from within > "uplevel #0 source binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp" > invoked from within > "catch "uplevel #0 source $test_file_name"" > > --- > > When reverting this patch, I no longer see the problem. Maybe it is deleting more than it should? Sorry, forgot to mention things work fine if you run the testsuite and the test serialized. If you pass -j2, for example, it runs into the problem above. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-19 14:26 ` Luis Machado @ 2023-06-19 17:12 ` Tom de Vries 2023-06-19 17:22 ` Tom Tromey 2023-06-21 5:31 ` Tom de Vries 2023-06-19 17:19 ` Tom Tromey 1 sibling, 2 replies; 12+ messages in thread From: Tom de Vries @ 2023-06-19 17:12 UTC (permalink / raw) To: Luis Machado, Tom Tromey, Tom de Vries via Gdb-patches On 6/19/23 16:26, Luis Machado wrote: > On 6/19/23 15:25, Luis Machado wrote: >> On 6/17/23 11:50, Tom de Vries via Gdb-patches wrote: >>> On 6/16/23 20:38, Tom Tromey wrote: >>>>>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes: >>>> >>>> Tom> Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works >>>> Tom> fine, but if we run it again with target board unix-m32, we run into: >>>> >>>> Thanks for doing this. >>>> >>>> If gdb's test suite could detect when a new .exp is started, we could >>>> make this always work by removing the corresponding standard output directory. >>> >>> Hi, >>> >>> thanks for the suggestion, I've implemented it in gdb_init. WDYT? >>> >>> Thanks, >>> - Tom >> >> Would this delete files unrelated to the specific test being executed? I started to see a number >> of errors in the testsuite where tests executed in parallel can't find gdb.log. >> >> For instance: >> >> --- >> >> ERROR: tcl error sourcing binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp. >> ERROR: couldn't open "outputs/gdb.arch/aarch64-sve/gdb.log": no such file or directory >> while executing >> "log_file -a outputs/gdb.arch/aarch64-sve/gdb.log" >> ("eval" body line 1) >> invoked from within >> "eval log_file $saved_log" >> (procedure "get_compiler_info" line 51) >> invoked from within >> "get_compiler_info $language" >> (procedure "test_compiler_info" line 4) >> invoked from within >> "test_compiler_info "clang-*"" >> (procedure "gdb_compile" line 41) >> invoked from within >> "gdb_compile $src $obj $type $compile_flags" >> (procedure "gdb_simple_compile" line 44) >> invoked from within >> "gdb_simple_compile $name $code $type $compile_flags temp_obj $default_compile_flags" >> (procedure "gdb_can_simple_compile" line 2) >> invoked from within >> "gdb_can_simple_compile aarch32 [join $list \n]" >> (procedure "gdb_real__is_aarch32_target" line 15) >> invoked from within >> "gdb_real__is_aarch32_target" >> ("uplevel" body line 1) >> invoked from within >> "uplevel 2 $real_name" >> (procedure "gdb_do_cache_wrap" line 3) >> invoked from within >> "gdb_do_cache_wrap $real_name {*}$args" >> (procedure "gdb_do_cache" line 48) >> invoked from within >> "gdb_do_cache is_aarch32_target" >> (procedure "is_aarch32_target" line 1) >> invoked from within >> "is_aarch32_target" >> (procedure "is_aarch64_target" line 6) >> invoked from within >> "is_aarch64_target" >> (procedure "gdb_real__allow_aarch64_sve_tests" line 6) >> invoked from within >> "gdb_real__allow_aarch64_sve_tests" >> ("uplevel" body line 1) >> invoked from within >> "uplevel 2 [list $real_name {*}$args]" >> invoked from within >> "gdb_do_cache_wrap $real_name {*}$args" >> (procedure "gdb_do_cache" line 48) >> invoked from within >> "gdb_do_cache allow_aarch64_sve_tests" >> (procedure "allow_aarch64_sve_tests" line 1) >> invoked from within >> "allow_aarch64_sve_tests" >> ("uplevel" body line 1) >> invoked from within >> "uplevel 1 $fn" >> (procedure "require" line 11) >> invoked from within >> "require allow_aarch64_sve_tests" >> (file "binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp" line 18) >> invoked from within >> "source binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp" >> ("uplevel" body line 1) >> invoked from within >> "uplevel #0 source binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sve.exp" >> invoked from within >> "catch "uplevel #0 source $test_file_name"" >> >> --- >> >> When reverting this patch, I no longer see the problem. Maybe it is deleting more than it should? > > Sorry, forgot to mention things work fine if you run the testsuite and the test serialized. If you pass -j2, for example, it > runs into the problem above. Hi, I can reproduce this, thanks for reporting this. It seems that gdb.log and gdb.sum are already there in the standard output file dir when the cleanup happens. I'm thinking about ways to work around this, but haven't come up with anything yet, so for now I've reverted this patch. Thanks, - Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-19 17:12 ` Tom de Vries @ 2023-06-19 17:22 ` Tom Tromey 2023-06-21 5:31 ` Tom de Vries 1 sibling, 0 replies; 12+ messages in thread From: Tom Tromey @ 2023-06-19 17:22 UTC (permalink / raw) To: Tom de Vries; +Cc: Luis Machado, Tom Tromey, Tom de Vries via Gdb-patches Tom> I'm thinking about ways to work around this, but haven't come up with Tom> anything yet, so for now I've reverted this patch. The only way I could think of was to have the deletion code be selective, and not delete gdb.{sum,log}. Maybe that's overkill though, considering how few tests really need this treatment. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-19 17:12 ` Tom de Vries 2023-06-19 17:22 ` Tom Tromey @ 2023-06-21 5:31 ` Tom de Vries 2023-06-21 7:40 ` Luis Machado 2023-06-22 16:01 ` Tom Tromey 1 sibling, 2 replies; 12+ messages in thread From: Tom de Vries @ 2023-06-21 5:31 UTC (permalink / raw) To: Luis Machado, Tom Tromey, Tom de Vries via Gdb-patches [-- Attachment #1: Type: text/plain, Size: 426 bytes --] On 6/19/23 19:12, Tom de Vries wrote: > I can reproduce this, thanks for reporting this. > > It seems that gdb.log and gdb.sum are already there in the standard > output file dir when the cleanup happens. > > I'm thinking about ways to work around this, but haven't come up with > anything yet, so for now I've reverted this patch. > OK, another try. This version handles the make -j 2 without problems. Thanks, - Tom [-- Attachment #2: 0001-gdb-testsuite-Clean-or-check-standard_output_file-di.patch --] [-- Type: text/x-patch, Size: 4483 bytes --] From ceadb531294172a7385c16320191853cefb946b9 Mon Sep 17 00:00:00 2001 From: Tom de Vries <tdevries@suse.de> Date: Sun, 18 Jun 2023 11:05:31 +0200 Subject: [PATCH] [gdb/testsuite] Clean or check standard_output_file dir in gdb_init In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some files at the start of the test-case: ... remote_file host delete [standard_output_file prog.o] remote_file host delete [standard_output_file prog.ali] ... Then in commit b7b77500dc5 ("[gdb/testsuite] Clean standard_output_file dir in gdb_init") I tried to do this more structurally, by cleaning up the entire standard_output_file directory, for all test-cases. This caused a regression when using "make check -j 2", due to the cleanup removing the active gdb.log, so I reverted the commit. Try again, this time handling the two cases separately. If the standard_output_file directory contains an active gdb.log, check that the directory contains no files other than gdb.log and gdb.sum. This puts the reponsibility for the cleanup at the callers in gdb/testsuite/Makefile.in which use --outdir. If the standard_output_file directory doesn't contain an active gdb.log, clean it by removing the entire directory. An exception is made for performance tests, where cleaning up the standard_output_file dir is the wrong thing to do, because an invocation with GDB_PERFTEST_MODE == run is intended to reuse binaries left there by an earlier invocation with GDB_PERFTEST_MODE == compile. Tested on x86_64-linux. Suggested-By: Tom Tromey <tom@tromey.com> --- gdb/testsuite/gdb.ada/call-no-debug.exp | 5 --- gdb/testsuite/lib/gdb.exp | 41 +++++++++++++++++++++++++ 2 files changed, 41 insertions(+), 5 deletions(-) diff --git a/gdb/testsuite/gdb.ada/call-no-debug.exp b/gdb/testsuite/gdb.ada/call-no-debug.exp index df81c87ade2..422b83761d9 100644 --- a/gdb/testsuite/gdb.ada/call-no-debug.exp +++ b/gdb/testsuite/gdb.ada/call-no-debug.exp @@ -21,11 +21,6 @@ require allow_ada_tests standard_ada_testfile prog -# Since we use no-force to compile prog, make sure we don't pick up files -# from a previous compilation. -remote_file host delete [standard_output_file prog.o] -remote_file host delete [standard_output_file prog.ali] - # Compile pck without debuginfo but prog with it. if {[gdb_compile_ada $srcdir/$subdir/$testdir/pck.adb \ [standard_output_file pck.o] object {}] != ""} { diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index f214a6bb54d..8a080636e7f 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -6286,6 +6286,45 @@ proc gdb_continue { function } { return [gdb_test "continue" ".*Breakpoint $decimal, $function .*" "continue to $function"] } +# Clean the directory containing the standard output files. + +proc clean_standard_output_dir {} { + if { [info exists ::GDB_PERFTEST_MODE] && $::GDB_PERFTEST_MODE == "run" } { + # Don't clean, use $GDB_PERFTEST_MODE == compile results. + return + } + + # Directory containing the standard output files. + set standard_output_dir [file normalize [standard_output_file ""]] + + # Ensure that standard_output_dir is clean, or only contains + # gdb.log / gdb.sum. + set log_file_info [split [log_file -info]] + set log_file [file normalize [lindex $log_file_info end]] + if { $log_file == [file normalize [standard_output_file gdb.log]] } { + # Dir already contains active gdb.log. Don't remove the dir, but + # check that it's clean otherwise. + set res [glob -directory $standard_output_dir -tails *] + set ok 1 + foreach f $res { + if { $f == "gdb.log" } { + continue + } + if { $f == "gdb.sum" } { + continue + } + set ok 0 + } + if { !$ok } { + error "standard output dir not clean" + } + } else { + # Start with a clean dir. + remote_exec build "rm -rf $standard_output_dir" + } + +} + # Default implementation of gdb_init. proc default_gdb_init { test_file_name } { global gdb_wrapper_initialized @@ -6420,6 +6459,8 @@ proc default_gdb_init { test_file_name } { set gdb_test_file_name [file rootname [file tail $test_file_name]] + clean_standard_output_dir + # Make sure that the wrapper is rebuilt # with the appropriate multilib option. if { $gdb_wrapper_target != [current_target_name] } { base-commit: 69141f080c01cca223ab061b85feacf17eeaf965 -- 2.35.3 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-21 5:31 ` Tom de Vries @ 2023-06-21 7:40 ` Luis Machado 2023-06-22 16:01 ` Tom Tromey 1 sibling, 0 replies; 12+ messages in thread From: Luis Machado @ 2023-06-21 7:40 UTC (permalink / raw) To: Tom de Vries, Tom Tromey, Tom de Vries via Gdb-patches On 6/21/23 06:31, Tom de Vries wrote: > On 6/19/23 19:12, Tom de Vries wrote: >> I can reproduce this, thanks for reporting this. >> >> It seems that gdb.log and gdb.sum are already there in the standard output file dir when the cleanup happens. >> >> I'm thinking about ways to work around this, but haven't come up with anything yet, so for now I've reverted this patch. >> > > OK, another try. This version handles the make -j 2 without problems. > > Thanks, > - Tom I've applied this patch and I can't reproduce the previous issues. The testsuite runs just fine in parallel. Thanks for investigating it. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-21 5:31 ` Tom de Vries 2023-06-21 7:40 ` Luis Machado @ 2023-06-22 16:01 ` Tom Tromey 1 sibling, 0 replies; 12+ messages in thread From: Tom Tromey @ 2023-06-22 16:01 UTC (permalink / raw) To: Tom de Vries via Gdb-patches; +Cc: Luis Machado, Tom Tromey, Tom de Vries Tom> OK, another try. This version handles the make -j 2 without problems. Looks good to me. Thanks. Reviewed-By: Tom Tromey <tom@tromey.com> Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp 2023-06-19 14:26 ` Luis Machado 2023-06-19 17:12 ` Tom de Vries @ 2023-06-19 17:19 ` Tom Tromey 1 sibling, 0 replies; 12+ messages in thread From: Tom Tromey @ 2023-06-19 17:19 UTC (permalink / raw) To: Luis Machado; +Cc: Tom de Vries, Tom Tromey, Tom de Vries via Gdb-patches Luis> Sorry, forgot to mention things work fine if you run the testsuite Luis> and the test serialized. If you pass -j2, for example, it runs Luis> into the problem above. I don't see see exactly this, but it does fail for me. I think what must be happening is that in parallel mode, dejagnu opens the .sum file before starting the test. However, starting the test then removes it, causing dg-extract-results to fail. Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-06-22 16:03 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-06-16 11:33 [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp Tom de Vries 2023-06-16 18:38 ` Tom Tromey 2023-06-17 10:50 ` Tom de Vries 2023-06-17 20:14 ` Tom Tromey 2023-06-19 14:25 ` Luis Machado 2023-06-19 14:26 ` Luis Machado 2023-06-19 17:12 ` Tom de Vries 2023-06-19 17:22 ` Tom Tromey 2023-06-21 5:31 ` Tom de Vries 2023-06-21 7:40 ` Luis Machado 2023-06-22 16:01 ` Tom Tromey 2023-06-19 17:19 ` Tom Tromey
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).