From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MymBHKKN62ng6DgAWB0awg (envelope-from ) for ; Fri, 24 Apr 2026 11:34:58 -0400 Received: by simark.ca (Postfix, from userid 112) id 5C82E1E0BA; Fri, 24 Apr 2026 11:34:58 -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.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 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 8001F1E067 for ; Fri, 24 Apr 2026 11:34:57 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 180164BB5910 for ; Fri, 24 Apr 2026 15:34:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 180164BB5910 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by sourceware.org (Postfix) with ESMTPS id E28E64BB3B97 for ; Fri, 24 Apr 2026 15:34:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E28E64BB3B97 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E28E64BB3B97 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.50 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777044871; cv=none; b=jgI6uoDVicPb3ej6tFkjibXOU4gx2KXmDKhV/DOLk2G0T317bL8Ov0xvJ1soc2UA07gzIIpIgiD6Px+7bwDka2xGLeJbVTtoIQxirKwyZkmtutOT9Zwh2Wgmwekjn7ACirkRTdML+hDRGhuoEvNGCK4+jb0RdkPkGcjtPmcV5Rg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777044871; c=relaxed/simple; bh=n/W89S7tmUrfQ3lLw9xOsLdd6NrMrkkyYD3vqlgQheE=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=QNgY7tegFvQ18LXu7oFpVDAYnzVr2B4WymPsHUokDAgBlrqsNNpqpk4nN+hkTvgxWTDzsEvK1p5m0jeZkIJKvLsdxDl6trya6DgGnwbrXjg7i6Pniq8TnDsP4GIFA86Has3ZI4LXLnHbQrdQMJtUUR4/DnSVIK7eQ39HscGZfKk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E28E64BB3B97 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-488a14c31eeso64360715e9.0 for ; Fri, 24 Apr 2026 08:34:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777044870; x=1777649670; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DwNlj8j+xdiA0q+GS6uVXDcn9MytCDIsmfB69CsIstk=; b=KSN02vzBraN9wLIOu6bC2HWtiEvRs/Jaf+CbCMNV4HL7/z/x8snvRbPWH+VvTas/Rp fO4K0MaqWUMWsmSet6tAWhlFjU0/GS6AmU4hwSlSY7k07P0nm/ede2h77beeYKlQIhuG PbR/OKuvjVV5xa58zjmx+yqi7wqMpas2Y6y0B+iMLtYr+DM6dVAIkoFMPym2EB8uomhB vLZ2CUYtbRpFW27JVCtzXC2d39Lye3WqBiSya0kOTuix3tsgIsbdMLQuLm0DR4w+SRgw 96NSgjxJwC+UWVf7L48Z7wev8heq67M8b47pVeEKG6MSXsh3EYQfQ4mZGMr3xAdZJgTA r4aw== X-Forwarded-Encrypted: i=1; AFNElJ8fip0XoVaLcAO/lc3J8XrJNwua/cMkNQrkUMjG++JV5eLGmT5kahG2Vw0KdQncUfRnEbFFj8mT5x6Q2A==@sourceware.org X-Gm-Message-State: AOJu0Yyp/+nKrUEMj9Scf/OiZi47dYRcRuzzKtkqeDfnQ8wcPsBt/Npc 0WIfP6uvkuvGJnXIDG2GQd0oofO/CJ+T3dlnTjF1GL4N3U14mm4IyHszR90eQ2Pk X-Gm-Gg: AeBDievmFA5fkomrfgLcMjc3JehjbHkud55lmeZ33bb1RSRZmsnKNTgWJSS1261KWLj MSk5VscjopNJfS3AQ/O9CiUGjSKwyYI1+rv5cB1v4vWQ1U7izYSmVh6uIDen1vpRAsnR8hHwa/N rw3sm0sUOl2dGIMh0ty6PpVDR0w6llttPZoLtDFJqfevrO/3cUSMmz4dBbM08bUQY6pD95ux3U7 DXZ02Jy3NBQQMAoSw905tHW8ATq/H3iYLO4j4Swek6kT9407BMHZQy3370t4tYOSXS9Avcdz5mM iAsrf/STXwDpaaYhmN2ZoJJt9VoVhKdeFaqkqx8nmdF3nny/UbEl1CAECAO2oLVECgYmo9KVZOW LLc+CelI0G/t9OgandfE0t2gXPyqjW+khWngP0uYXTYwEUCAQZcvmrFj/X9C9BKFcxb5VBmb8WA ZMbbbvCren7wOsfmhs3oISu2ch4y5Md3oT+0nsm5DjIxLmq/s5FZx29VUCZEmOnkgeOHrC8UYv1 g== X-Received: by 2002:a05:600c:3150:b0:480:3ad0:93bf with SMTP id 5b1f17b1804b1-488fb7930famr466082715e9.24.1777044869517; Fri, 24 Apr 2026 08:34:29 -0700 (PDT) Received: from ?IPV6:2001:8a0:facb:a800:93fe:74c:b5c1:aafd? ([2001:8a0:facb:a800:93fe:74c:b5c1:aafd]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4891c318636sm395344355e9.7.2026.04.24.08.34.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Apr 2026 08:34:28 -0700 (PDT) Message-ID: <3d0651b0-c549-4077-98e5-723b27c23679@palves.net> Date: Fri, 24 Apr 2026 16:34:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Don't pretend infcalls don't set the inferior running (PR gdb/34082) To: Andrew Burgess , gdb-patches@sourceware.org References: <20260423184946.1128623-1-pedro@palves.net> <87zf2s215u.fsf@redhat.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <87zf2s215u.fsf@redhat.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 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. > > 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 >