Re: [pushed] [gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp

[Tom de Vries <tdevries@suse.de>]

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