From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wux/N7GdZWP3KhQAWB0awg (envelope-from ) for ; Fri, 04 Nov 2022 19:18:09 -0400 Received: by simark.ca (Postfix, from userid 112) id D84F41E124; Fri, 4 Nov 2022 19:18:09 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=E937s45A; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 758601E11E for ; Fri, 4 Nov 2022 19:18:09 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2A38C385843F for ; Fri, 4 Nov 2022 23:18:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2A38C385843F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667603888; bh=OZKwQgBo7kTSnHTHtBWqnb+3U6nUrlmYtgN0kaKHB54=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=E937s45AHFF2BJZyELY6x5uyOX8jeB0z1QEPtNhLHVd3MBGeygjc7Lll8obXJ0VlR p9tzN7C5k94fajydIZqY12tGonNGZqn+TfBf0G+uIm1eomwD7kc2gcVckXzc1z7J1J aejKOmjeKD0ILrE5pRVLoInz2EKLi7Y9CxY2lLyo= Received: from lndn.lancelotsix.com (lndn.lancelotsix.com [51.195.220.111]) by sourceware.org (Postfix) with ESMTPS id 7DFCC3858D35 for ; Fri, 4 Nov 2022 23:17:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7DFCC3858D35 Received: from ubuntu.lan (unknown [IPv6:2a02:390:9086::635]) by lndn.lancelotsix.com (Postfix) with ESMTPSA id 8CEB280017; Fri, 4 Nov 2022 23:17:47 +0000 (UTC) Date: Fri, 4 Nov 2022 23:17:34 +0000 To: Andrew Burgess Subject: Re: [PATCH 11/12] gdb: add timeouts for inferior function calls Message-ID: <20221104231700.evhnzbuwexevh2hd@ubuntu.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (lndn.lancelotsix.com [0.0.0.0]); Fri, 04 Nov 2022 23:17:47 +0000 (UTC) X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Lancelot SIX via Gdb-patches Reply-To: Lancelot SIX Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi, > In this commit I propose a solution to this problem. A timeout. For > targets that support async-mode we can install an event-loop timer > before starting the inferior function call. When the timer expires we > will stop the thread performing the inferior function call. With this > mechanism in place a user can be sure that any inferior call they make > will either complete, or timeout eventually. > > Adding a timer like this is obviously a change in behaviour for the > more common 'call' and 'print' uses of inferior function calls, so, in > this patch, I propose having two different timers. One I call the > 'direct-call-timeout', which is used for 'call' and 'print' commands. > This timeout is by default set to unlimited, which, not surprisingly, > means there is no timeout in place. > > A second timer, which I've called 'indirect-call-timeout', is used for > inferior function calls from breakpoint conditions. This timeout has > a default value of 300 seconds. This is still a pretty substantial > time to be waiting for a single inferior call to complete, but I > didn't want to be too aggressive with the value I selected. A user > can, of course, still use Ctrl-c to interrupt an inferior function > call, but this limit will ensure that GDB will stop at some point. > I do see the use of the indirect call timeouts, and I find it a good solution for the problem you are trying to solve. I am however not sure I see much usecase for the direct one. It looks to me that using Ctrl-C serves this purpose well already. Do you have a use case in mind where this can come in handy? Scripting and automation maybe? It seems to me that only having the setting for the indirect call timeout would make the interface simpler. That being said, once you have implemented the mechanism for the "indirect" calls, "direct" call timeout implementation comes for free. I guess this was your reasoning. Lancelot.