Re: [PATCH 4/7] gdb/testsuite: fix step-over-thread-exit.exp with native-gdbserver

[Simon Marchi <simon.marchi@polymtl.ca>]

On 5/12/26 9:06 AM, Aktemur, Baris wrote:
> AMD General
> 
> Hi Simon,
> 
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>>
>> This test uses "set args N" to control how many threads the inferior
>> spawns: 1 in some cases and 100 in others.  However, "set args" doesn't
>> work with the native-gdbserver board.  As a result, with that board, the
>> inferior always uses its default of 100 threads.  It sometimes causes
>> failures like:
>>
>>     p $_thread == 2
>>     $1 = 1
>>     (gdb) [New Thread 2790806.2790823 (id 3)]
>>
>>     Thread 3 "step-over-threa" hit Breakpoint 2, 0x00005555555552ab in my_exit_syscall
>> () at /.../testsuite/lib/my-syscalls.S:85
>>     85      SYSCALL (my_exit, __NR_exit)
>>     FAIL: gdb.threads/step-over-thread-exit.exp: step_over_mode=inline: non-stop=on:
>> target-non-stop=on: schedlock=off: cmd=next: ns_stop_all=0: selected thread didn't
>> change (timeout)
>>
>> Here, GDB steps over thread 2's exit.  As soon as thread 2 exits, the
>> main thread spawns a new thread (thread 3), which hits the breakpoint
>> placed over the exit syscall, and that event gets reported
>> asynchronously, confusing the testsuite.  The point of setting n_threads
>> to 1 is exactly to avoid things like that.
>>
>> Fix it by passing the args via the new -inferior-args option, which
>> works correctly with the native-gdbserver board.
>>
>> Change the test program to requiring the number of threads to be passed
>> as an argument, which would have caught this problem.
>>
>> Change-Id: Ifc8856aa582706fd7207d0035d35dee749eb83a5
>> Reported-By: Tankut Baris Aktemur <Tankut.Aktemur@amd.com>
> 
> I was at Intel when I reported it.  Could you please use
> tankut.baris.aktemur@intel.com here?
Ack.

Simon