From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 1sjiI+7K72mjTz8AWB0awg (envelope-from ) for ; Mon, 27 Apr 2026 16:45:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1777322734; bh=0PW2mtmcJuulJ0X0K4n6PAAq4gcmS91/x6NBDYH2Bbo=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=cukd6iTiirKI9791Psg3e5Iipa4ictdVM4+KKG2hzJHfIASGa1HfzBYvPtjMdXwu9 /S4GVIJ8iSKtoM+rNQpQHjqs7bWjdOwc4smnMU2wykowc29Gf5GOIf6d7zTsbTcTTR OcLUBr05GRBmqUWg6J+kT3Ddwq/Ga9/YFShhICC4= Received: by simark.ca (Postfix, from userid 112) id 7C3D81E0BA; Mon, 27 Apr 2026 16:45:34 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=B4E+D1lB; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B99EB1E093 for ; Mon, 27 Apr 2026 16:45:33 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 5CBDA4BA799C for ; Mon, 27 Apr 2026 20:45:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5CBDA4BA799C Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=B4E+D1lB Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 2C85A4BA23F7 for ; Mon, 27 Apr 2026 20:45:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2C85A4BA23F7 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2C85A4BA23F7 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777322701; cv=none; b=fXAxv0TsZIVRnETGl8kUeNl8dELIdrHZu88j3elHg3LaonhuyiuX1c9LeMbYLGrrClQ7arGTJ5baSNHn0dT2vfd4GxtPUsjd4gHu8GigsRcid+9VXs/eFLU6iPKjuyCLLw4LIeXHU58mgXj+mBfJmTKtK5gGyWYDHYHlVz+CmyU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777322701; c=relaxed/simple; bh=0PW2mtmcJuulJ0X0K4n6PAAq4gcmS91/x6NBDYH2Bbo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=GQ0kv/oOKpYOaGuwpWzQvuS+k4J5oFyzuKvNpSINeM5qIKVtnI4fZi9OXBk2JRSaDDINFBRNeUmyf2JlfSe9gs4QT4GNOfYCcNmYV/s514odeqGO1sauLm+Yl20H6cvebsFz9B9jeKB0q/2GthIMg/NgGGBAbe/5+9O2wlmKqrI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C85A4BA23F7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1777322700; bh=0PW2mtmcJuulJ0X0K4n6PAAq4gcmS91/x6NBDYH2Bbo=; h=Date:Subject:To:References:From:In-Reply-To:From; b=B4E+D1lB1Tr/0Laf19fUDiCT4KbQGyVLdGQ2X+/8ZiSZdpMthkXcDvGzMc4KAp1RB gyllMhRb0/6PEFbRSKtqertCAypLJWjGugFQScnRITuJybUaRH+9eaCHSaxGkDy6Yx faGXAcxFhOMqy60tc6UDCtvvU2USMu5oiDjfU0ow= Received: by simark.ca (Postfix) id 8DFCD1E093; Mon, 27 Apr 2026 16:44:59 -0400 (EDT) Message-ID: <3c2f05b4-094b-4cf3-8f6f-35c8538843f4@simark.ca> Date: Mon, 27 Apr 2026 16:44:58 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb, testsuite: use -no-prompt-anchor in step-over-thread-exit.exp To: Tankut Baris Aktemur , gdb-patches@sourceware.org References: <20260424141955.4083734-1-tankut.baris.aktemur@intel.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20260424141955.4083734-1-tankut.baris.aktemur@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org 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. Simon