From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Yef9Clel+2mXWBsAWB0awg (envelope-from ) for ; Wed, 06 May 2026 16:32:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1778099543; bh=A68chzCtaY7T9ga5fQPGCr5hFUYgH1zwzlbB3byZ7lo=; h=Date:Subject:From:To:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=LEBLnl6K0EBj6uvFV9EGH2lhAGwNzl4luii/wPq0FlzAfFqncYzzA8QpsBauzDkDz poxdefID1vkW5ISh9CvBvBEnAw55wbtpNAK8qdo3MgrlfhXsSjXr5WOpD0hcHiyLmp 7BDwYbzaFF3yg0F6JCP4HC1Ujp6exkb4s+Vr3N34= Received: by simark.ca (Postfix, from userid 112) id 265761E0BA; Wed, 06 May 2026 16:32:23 -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=sxTCq1/f; 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 6A51D1E067 for ; Wed, 06 May 2026 16:32:22 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id ECBAC4BA23DC for ; Wed, 6 May 2026 20:32:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ECBAC4BA23DC 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=sxTCq1/f Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id E7C384BA23E9 for ; Wed, 6 May 2026 20:31:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E7C384BA23E9 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 E7C384BA23E9 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778099515; cv=none; b=xw+NiMlf/w/+Q2Q52gJf5TTSI04XEBm6GXdcSeCgDpAwE6jVUy7isgJx4tE/tHYWqwFCtxdTtqF840IFdusgdtPmLSUvHttKemmG5aDuM/oxXOFNVtp67WaVZkaRYUmzWerRjiLSdq5bPUZS/VnkuTSHBskMIRuC38kBCbo+e88= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778099515; c=relaxed/simple; bh=A68chzCtaY7T9ga5fQPGCr5hFUYgH1zwzlbB3byZ7lo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:From:To; b=nhy6ly2VRflB1xtcdVreeViYm2/IxiE0thdKTzIHCGtDH0kjt84ML4erlrE81hNJVAgKIuW71ZCzVbGBS5zM76YKHOjFaD8oRbi02IZLTSFSYFVCtkn0KiZZqO3Y+CRHi9T8kud89rP8VXCgjNIX4cuzkhPOr6zHaTPC331JnQI= ARC-Authentication-Results: i=1; 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=sxTCq1/f DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E7C384BA23E9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1778099508; bh=A68chzCtaY7T9ga5fQPGCr5hFUYgH1zwzlbB3byZ7lo=; h=Date:Subject:From:To:References:In-Reply-To:From; b=sxTCq1/fR4S+53HFXVWVl/mD6/71dbZqAlycKyojv8sf+nuN8ZxRxO6LsveAlRBq8 +zqvmB8gQvhfwXIg9l9X3D3an2yopZMupzz5aO3lwcXZMryrVBRtmskJTDbM/DzT3B Q4IpSGy59Wn8Kz3juwsK+lPZNEcMjf0OixXEuA2M= Received: by simark.ca (Postfix) id 23B531E067; Wed, 06 May 2026 16:31:47 -0400 (EDT) Message-ID: <83bd7517-7cb1-4f79-ae46-b9810f6bcc93@simark.ca> Date: Wed, 6 May 2026 16:31:46 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb, testsuite: use -no-prompt-anchor in step-over-thread-exit.exp From: Simon Marchi To: gdb-patches@sourceware.org, Tankut.Aktemur@amd.com References: <20260424141955.4083734-1-tankut.baris.aktemur@intel.com> <3c2f05b4-094b-4cf3-8f6f-35c8538843f4@simark.ca> Content-Language: en-US In-Reply-To: <3c2f05b4-094b-4cf3-8f6f-35c8538843f4@simark.ca> 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 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