From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KZN1EnKv8WkBjAIAWB0awg (envelope-from ) for ; Wed, 29 Apr 2026 03:12:50 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=LrTb4tcD; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 3665F1E0BA; Wed, 29 Apr 2026 03:12:50 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 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 0D1401E093 for ; Wed, 29 Apr 2026 03:12:49 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 26CEB4BB8F45 for ; Wed, 29 Apr 2026 07:12:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 26CEB4BB8F45 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=LrTb4tcD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id D19B04BB24C1 for ; Wed, 29 Apr 2026 07:12:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D19B04BB24C1 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D19B04BB24C1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777446741; cv=none; b=UAxvq0PhhobIXH4gmWcKHdMMf3UGpQyzN8a+fk0lkM2OvA03vPbn4P0ZdpouA/SEJmW29Bs0rdVt9bRnTNnA1hV2OfDbwR0BeYVPbS2G4X/CVC+Gfyxlq0zwOSYEh/eVez4XP7iW2HcJ/geGi7qbXXwUu0JM+f7YpfB535sXYpU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777446741; c=relaxed/simple; bh=bEajHYJrY7YNxYSlfG2hQZB95BwMu22LlHct+RT4Jw4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=LKdXlV1048aFl7qXlnG1HFotsAIox4/JUUj9kjQQ/kNspyy4RlHwlvWme5mLkvr6L3aKYyhVwyB6hpsCjtVVhMtaJB4GedhohKVH/f8wsriF+LDbToWl0BLuZpVRllq0SDv8M10MPYTCMccQGvhe37TaHmEtAzuEmcHB2w+eK9w= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D19B04BB24C1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1777446740; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xtVnPNjq+QD6X/3NazduZOflvTXe5LY7/UFFgrEJRng=; b=LrTb4tcD/e/VqVrVllbedIB1ym1hXNCbt3cSqpqOo4JZGcBtm2eLsvSRm/xRGz4TeLk9T7 JnCmxd9lcJb5Bmi6yw2Kyjz94O3DbRryVQhuJKw5A6lNb3YwlPb9N4f9CIPB0gRCyQmkkf c96GxQtRwN792uwHNuKvruhZlJucpI0= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-527-j7r_fOagO36PjUJAxJkNzw-1; Wed, 29 Apr 2026 03:12:19 -0400 X-MC-Unique: j7r_fOagO36PjUJAxJkNzw-1 X-Mimecast-MFC-AGG-ID: j7r_fOagO36PjUJAxJkNzw_1777446738 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-43ff0eb2b2aso9443408f8f.2 for ; Wed, 29 Apr 2026 00:12:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777446737; x=1778051537; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xtVnPNjq+QD6X/3NazduZOflvTXe5LY7/UFFgrEJRng=; b=g4wb7cTb8lBgsdpaOWljXQVyAp4fVte3Dqs63L0zQBnWIRPWLw1I6Tumz0PnHnnC8k Z7BST9MOWSK3wjrU5Tv153ma3sH8uTP+Vq6o/TTM11iR8ZQcOKeT3phWF0qO+UVypiCb 5xWo89n4rcSewVRFKiQEY0OkCSXb5soqevxACKJpNdsP3ONivFrps2a+5VDf1Nqa3Ltn 3iPHK0qsqYRsgzrbdnut4mZxDeC5KHzAKV9RqqrwadVIkHvcVWrw1zfW/jQaqdnI7sP9 N7hJJlz5AFabd04xFK9uwljtQgWvHjhBOMmmJ0AZJXRaz8oYxvd8rEKMzFj4PnCT+He7 lmQw== X-Forwarded-Encrypted: i=1; AFNElJ/vU9/4CzudDuu2puI09jhkdJgbxFfmpVH2EI+mpGUcMGWXPw/hhBEAyLn14EX7hQRSq6F0ixdHASXELg==@sourceware.org X-Gm-Message-State: AOJu0Yy7m9fgfwM6wGqj8HZYr+RJZ0RzhYM0iYjRgy+4LdJM8OjSMfPA +tLCJOsa/1uyOGRqgAZP9jNpe0V1noqnSZky0Zb2cuoi0NM3prE9fzRd4TjTIK3GvYgLkfjuaez 7bV7egmxxwunp5e7ezJ7swlGLb/5xBqDxjOiSek4p3n7FXVGvIYZWJdgULo8022IO/9JCMvw= X-Gm-Gg: AeBDiesMT2w9f7vT2w89XwrsGDQZNYFxIQ6GQ2BcV3fGAi2NRPecUfIx2GTmtWy5DnB 5/71b7c9bkr8B5G4637D6aVxViOqH9feWI/K5JVsCqZ1ydKA6NdxzHrw4QWMcHdYp4Z6LWAz6zy zxOKJY5NWX53QgWcpGIBXTUCsJcICW69AXcaj+wQOz/VGUCPbB0rBH7fofOekGxnuB05oNJHylV n6d3yBl5rdzgc340IKP0z7Xcx/m5lFevkNa/Cwo8zg+qe6DFpwJgm5BdbOiOKuYZKsRgb30qoUg nm//Znd+BhZMk20Db17sjOczko+tG6iY3Qtg/zRkBA62nraYdntfg5tt0p0Q5nvqDYbGyABqZyt 6U1MEzJF+yAfV15RCUeG+rH93QLc= X-Received: by 2002:a05:6000:2f84:b0:43c:f1a5:56f6 with SMTP id ffacd0b85a97d-4464a070437mr11251578f8f.43.1777446737213; Wed, 29 Apr 2026 00:12:17 -0700 (PDT) X-Received: by 2002:a05:6000:2f84:b0:43c:f1a5:56f6 with SMTP id ffacd0b85a97d-4464a070437mr11251499f8f.43.1777446736596; Wed, 29 Apr 2026 00:12:16 -0700 (PDT) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-447b7ca67b9sm3013915f8f.34.2026.04.29.00.12.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2026 00:12:15 -0700 (PDT) From: Andrew Burgess To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH] Don't pretend infcalls don't set the inferior running (PR gdb/34082) In-Reply-To: <3d0651b0-c549-4077-98e5-723b27c23679@palves.net> References: <20260423184946.1128623-1-pedro@palves.net> <87zf2s215u.fsf@redhat.com> <3d0651b0-c549-4077-98e5-723b27c23679@palves.net> Date: Wed, 29 Apr 2026 08:12:14 +0100 Message-ID: <87mrym1bqp.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: vwxYTuznnpqOPyAL8tdjoVWRdbLyqdfqx0el91M2mQI_1777446738 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Pedro Alves writes: > On 2026-04-24 09:49, Andrew Burgess wrote: >> >> Pedro, >> >> Thanks for fixing this. No real problems, one trivial nit, and a >> question, see below... >> >> >> Pedro Alves writes: >>> I think the right fix is to stop pretending that infcalls don't set >>> the target running. I can't think of a reason we do that. It really >>> does run. Some thoughts: >>> >>> - I added to code to skip set_running (nowadays 'set_state(..., >> >> typo: "I added to code" -> "I added THE code" ? > > Yes, thanks, fixed. > >> >>> THREAD_RUNNING))' for infcalls back in commit 4d9d9d0423 over 10 >>> years ago, but I honestly don't recall why. My guess is that it >>> must have been to keep backwards compatibility with something, and >>> the code has probably changed sufficiently since then making it no >>> longer necessary. >>> >>> - infcalls are always synchronous, so the intermediate running state >>> can't be observed with commands. >> >> I assume you mean by this that infcalls are something the user initiates >> from the prompt, and so while the infcall is running the user cannot >> also ask to inspect the thread state. >> >> I don't disagree with any of your conclusions, but, if an infcall is >> made as part of a breakpoint condition, then than could run in the >> background, asynchronously, while the user is also issuing other >> commands. > > No, it really can't. Try something like this: > > ~~~~~~~~~~~~~~~~~~~~~~~~ > #include > > static int > foo (void) > { > usleep (1); > return 0; > } > > int > return_false () > { > sleep (10); // <=== each condition eval will do an infcall that takes 10s. > return 0; > } > > int > main (int argc, char **argv) > { > while (1) > foo (); > return 0; > } > ~~~~~~~~~~~~~~~~~~~~~~~~ > > > $ gdb -q ./a.bout -ex "start" > ... > Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd888) at test.c:64 > 64 foo (); > (gdb) b foo if return_false () > Breakpoint 2 at 0x5555555551b1: file test.c, line 26. > (gdb) c& > Continuing. > (gdb) info threads > * hangs for up to 10 seconds here * > info threads > Id Target Id Frame > * 1 Thread 0x7ffff7f8f740 (LWP 1821559) "hand-call-new-t" (running) > (gdb) > Id Target Id Frame > * 1 Thread 0x7ffff7f8f740 (LWP 1821559) "hand-call-new-t" (running) > (gdb) p 1 > * hangs for up to 10 seconds here * > p 1 > $1 = 1 > (gdb) > > You have to try it to get a feel, but what happens is that GDB does not react > to commands while the infcall is ongoing, leading to those up to 10 seconds "hangs". > > See here, in infcall.c:run_inferior_call: > > > /* Infcalls run synchronously, in the foreground. */ > scoped_restore restore_prompt_state > = make_scoped_restore (¤t_ui->prompt_state, PROMPT_BLOCKED); > > ... > proceed (); > ... > > /* Inferior function calls are always synchronous, even if the > target supports asynchronous execution. */ > wait_sync_command_done (); > > > There's an old > "SNIP - SNIP - SNIP - SNIP - SNIP - SNIP - SNIP - SNIP - SNIP" > line in infcall.c that suggests where we'd split the infcall machinery into a state machine. > > > But I think it'd be way more complicated than that hint suggests, infcalls happen in > the middle of expression evaluation, and the state for the expression is all on the stack. > We can't go back to the top event loop in the middle of an expression. Not to mention > we evaluate expressions all over the place, in the most innocuous-looking commands. > Any parse_and_eval with user input is potentially an infcall. > > > Also, if it were possible to issue command while a breakpoint condition is in the middle > of an infcall, the thread should still be considered THREAD_RUNNING up until the condition > evals false, meaning it really causes a user-visible stop. So in that scenario, while > running the infcall, the thread would have been THREAD_RUNNING all the while, meaning, > there would be nothing new the user would be able to observe with this > change. Thanks for taking the time to explain this. That all makes sense. Thanks, Andrew > >> >> Not that this changes anything. In this situation the user believes >> that the inferior is running in the background, so seeing the threads as >> running is absolutely fine. I'm just not convinced that the claims made >> in this point "infcalls are always asynchronously" and "the intermediate >> running state can' be observed" are correct. >> >> But the patch itself makes a lot of sense, and looks good. >> >> Approved-By: Andrew Burgess > > Thanks. > > Pedro Alves > >> >> Thanks, >> Andrew >>