Re: [PATCH] gdb/testsuite: fix failure in gdb.server/fetch-exec-and-args.exp

[Andrew Burgess <aburgess@redhat.com>]

Simon Marchi <simark@simark.ca> writes:

> On 1/14/26 3:01 PM, Andrew Burgess wrote:
>> Bug PR gdb/33792 reported a gdb.server/fetch-exec-and-args.exp FAIL
>> when using the native-gdbserver board:
>> 
>>   FAIL: gdb.server/fetch-exec-and-args.exp: packet=on: set_remote_exec=false: test_server_with_no_exec: show remote exec-file
>> 
>> The actual test output looks like this:
>> 
>>   (gdb) show remote exec-file
>>   The remote exec-file is unset, using automatic value "/tmp/build/gdb/testsuite/outputs/gdb.server/fetch-exec-and-args/fetch-exec-and-args".
>>   (gdb) FAIL: gdb.server/fetch-exec-and-args.exp: packet=on: set_remote_exec=false: test_server_with_no_exec: show remote exec-file
>> 
>> This test actually fails with native-gdbsever and
>> native-extended-gdbserver boards.  The problem is that these boards
>> clear the sysroot.
>> 
>> This exact test has the following conditions:
>> 
>>   + The qExecAndArgs is in use (see 'packet=on').
>> 
>>   + We're not explicitly doing 'set remote exec-file ...' (see
>>     'set_remote_exec=false').
>> 
>>   + The test starts gdbserver without an executable (see
>>     'test_server_with_no_exec').
>> 
>>   + And because of the native-gdbsever board, the sysroot is "".
>> 
>> What this means is that GDB knows that gdbserver doesn't have an
>> executable thanks to qExecAndArgs, the user hasn't set an executable
>> for GDB to use when starting a new inferior, but GDB does know that
>> GDB and gdbserver can see the same filesystem due to the sysroot
>> setting.  GDB will then automatically use the current executable as
>> the remote executable name.  The test script doesn't expect this case,
>> and so the test fails.
>> 
>> Fix this by adjusting the script to expect the 'using automatic value
>> ...' text when appropriate.
>> 
>> I also extended the test_server_with_no_exec proc to take a new flag
>> 'clear_sysroot', we now run the test with the sysroot set to 'target:'
>> and with the sysroot set to "", even when using the 'unix' board.
>> 
>> Additionally, I ran the test through check-all-boards and found one
>> additional failure, when using --host_board=local-remote-host-native
>> and --target_board=local-remote-host-native.  In this case GDB copies
>> the executable to the remote host, which changes its filename.  When
>> the filename appears in the 'using automatic value ...' text, I was
>> expecting the filename assuming a local host.
>> 
>> I could fix this, but it doesn't seem worth the extra complexity for
>> this one test, so I've just set the test to be skipped for that one
>> configuration.
>> 
>> Now, when using check-all-boards, I'm seeing no failures.
>> 
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33792
>
> It appears to fix the failure on my side.  Thanks for the quick fix and
> for improving the test.
>
> Approved-By: Simon Marchi <simon.marchi@efficios.com>

I forgot about this one.  Now pushed.

Thanks,
Andrew