Re: [PATCH] gdb, testsuite: use -no-prompt-anchor in step-over-thread-exit.exp

[Simon Marchi <simark@simark.ca>]

On 2026-04-27 16:44, Simon Marchi wrote:
> On 4/24/26 10:19 AM, Tankut Baris Aktemur wrote:
>> Running gdb.threads/step-over-thread-exit.exp with the
>> native-gdbserver boardfile sometimes fails with
>>
>>   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)
>>
>> The passing case is
>>
>>   p $_thread == 2
>>   $1 = 1
>>   (gdb) PASS: 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
>>   Remote debugging from host 127.0.0.1, port 32932
>>   [New Thread 2784047.2784049 (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)
>>
>> Fix the problem by using -no-prompt-anchor.  Since this is non-stop
>> mode, it should be ok to use the flag.
> 
> I'm trying to understand more deeply what happens and try to reproduce
> it reliable.
> 
> First of all, I was confused by the the "Remote debugging from host"
> message, but that is from gdbserver, not GDB, so it doesn't come into
> play in the "gdb_test" matching, ok.
> 
> What happens is that after the "next" that produces "Command aborted,
> thread exited", another thread (thread 3) is created and hits the
> syscall breakpoint.  And since this is non-stop, it can be shown at
> anytime.
> 
> But why would that be specific to native-gdbserver?  We have:
> 
> 	if {$cmd != "continue" || $step_over_mode == "none"} {
> 	    set n_threads 1
> 	} else {
> 	    set n_threads 100
> 	}
> 
> 	gdb_test_no_output "set args $n_threads"
> 
> n_threads should be 1, the program should not spawn a another thread
> that hits the breakpoint, why does it?  $cmd is "next" and
> $step_over_mode is "inline".  Perhaps the args don't reach the test
> program correctly when ran with native-gdbserver?
> 
> I changed the test program to exit with an error when argc != 2 (the
> test should always pass an explicit number of threads, so there is no
> point in having a default value of 100). And indeed, this shows that
> n_threads doesn't reach the test program.  "set args" doesn't work with
> native-gdbserver.
> 
> Setting n_threads to 1 is meant to avoid this kind of problem:
> 
> 	# With step/next, GDB aborts the execution command with
> 	# "Command aborted, thread exited." when the stepping thread
> 	# exits.  If we let the main spawn another thread as soon as
> 	# the first exits, it would be possible for that new thread to
> 	# hit the exit syscall insn breakpoint quickly enough that it
> 	# would be reported to be user before the first thread exit
> 	# would be, which would confuse testing.  To avoid that, we
> 	# only spawn one thread, too.
> 
> What we see here seems to be a variation of that.
> 
> See this commit (especially the "Fixes a race" part of the commit
> message):
> 
> https://gitlab.com/gnutools/binutils-gdb/-/commit/4ea7412e53616ecc29d61a95ff8afc284ed9d240
> 
> I guess that this n_threads fix was broken with native-gdbserver since
> then?
> 
> I propose to do the following changes:
> 
>  - Pass `n_threads` by poking the variable from GDB once the program was
>    started and is stopped at main.  Alternatively, it would be nice to
>    change "runto" and friends to be able to pass inferior args, that
>    would be nicer than poking variables manually, but that is a bigger
>    project.  Today, we can use gdb_run_cmd to pass args to the test
>    program, but it would be nice to be able to use the higher level
>    runto/runto_main for this.
> 
>  - Use `-wrap` in the gdb_test_multiple "command aborts when thread
>    exits", or better yet turn it into a simple gdb_test.  Since there
>    shouldn't be another thread spawned after the one that exits during
>    the step, we shouldn't see anything after the prompt.
> 
> I just saw that the test relies on a "sleep (3)" in the main thread,
> just before the process exits, which isn't great.  I suppose this could
> (unlikely) happen:
> 
>   - step command completes, prints the "Command aborted, thread exited"
>     message plus prompt
>   - main thread goes into sleep (3)
>   - expect somehow doesn't get scheduled for > 3 seconds
>   - main thread exits
>   - gdb prints "inferior exited blah blah blah"
>   - expect wakes up and reads the GDB output, test fails because there
>     is output after the prompt
> 
> The same problem could also mess up the "p $thread == ..." test, exactly
> how you described in the commit message.  I think we should remove that
> sleep and replace it with a global variable "allowed to exit" flag that
> GDB sets to let the main thread exit (but as another patch).  It might
> also make the test run faster in the cases where it reaches exit.

I sent a series that teaches the testsuite to properly pass
arguments to inferior programs (even with the native-gdbserver board),
and used it to fix the problem above.

https://inbox.sourceware.org/gdb-patches/20260506202804.1681886-1-simon.marchi@polymtl.ca/T/#m9a8716af21f9f31b3a5cf1abcdadb522d6c45e9f

Simon