From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qWdbO7KWwmNkvBYAWB0awg (envelope-from ) for ; Sat, 14 Jan 2023 06:49:06 -0500 Received: by simark.ca (Postfix, from userid 112) id E7E131E128; Sat, 14 Jan 2023 06:49:06 -0500 (EST) 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=Qb8bbSvb; 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=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, 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 04E671E112 for ; Sat, 14 Jan 2023 06:49:04 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 451F8383FB84 for ; Sat, 14 Jan 2023 11:49:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 451F8383FB84 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1673696943; bh=XGHerwBLYUQlssk4+YIjHiHDEwXP7JPeH3Ea/q55BEs=; h=Date:To:Cc:In-Reply-To:Subject:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Qb8bbSvbzuqRaWsiFze/1snh6icR5JgnqBCpHQ2lnXfiI/QT8OJrwTYygolXemSfe q+yyiIs+B/zei7Y1+/rUg0RIkc22GdEfRdwqyeOteOhwv8VttLHxef3PhC9E6rnb5B BO6M23lYydZCGd2kRSY3ROPhZdIZDEEeF7vwk4Ng= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id A37D73858C50 for ; Sat, 14 Jan 2023 11:48:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A37D73858C50 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGf1f-00019p-Qf; Sat, 14 Jan 2023 06:48:43 -0500 Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGf1e-0002Lc-TO; Sat, 14 Jan 2023 06:48:43 -0500 Date: Sat, 14 Jan 2023 13:48:45 +0200 Message-Id: <83wn5p72w2.fsf@gnu.org> To: Andrew Burgess Cc: gdb-patches@sourceware.org In-Reply-To: <87ilh9fkj3.fsf@redhat.com> (message from Andrew Burgess on Sat, 14 Jan 2023 11:00:32 +0000) Subject: Re: [PATCH 11/12] gdb: add timeouts for inferior function calls References: <83a65pwi1h.fsf@gnu.org> <87ilh9fkj3.fsf@redhat.com> 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: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > From: Andrew Burgess > Cc: gdb-patches@sourceware.org > Date: Sat, 14 Jan 2023 11:00:32 +0000 > > >> +@table @code > >> +@item set direct-call-timeout @var{seconds} > >> +@kindex set direct-call-timeout > >> +@cindex timeout for called functions > >> +Set the timeout used when calling functions in the program to > >> +@var{seconds}, which should be an integer greater than zero, or the > >> +special value @code{unlimited}, which indicates no timeout should be > >> +used. The default for this setting is @code{unlimited}. > > > > Why integer in seconds? don't we want to be able to support shorter > > timeouts, like 100 msec? Most inferior calls should take much less > > than a second, so a second resolution is not the best idea, IMO. It > > could, for example, make running a program with such a breakpoint > > unbearably slow. > > Remember, this timeout is a safety net intended to catch situations > where either due to a bug in the inferior, or due to user error, the > breakpoint condition is never going to complete. > > As such I don't think we should be trying to trim this value down as low > as possible, I just don't see any additional value, in fact, I see doing > so adding more risk that the user will hit invalid timeouts. > > If you wanted to be super aggressive with the timeout, and you set it to > 1 second, but you still expect your inferior calls to complete in > 100msec, then the timeout being 1 second will not slow you down in any > way. But, if for some reason your inferior call deadlocks, you'll end > up waiting that complete second before GDB gives up. > > I can't imagine a use case where a user will be debugging by having an > inferior function call repeatedly timeout, and that's the only way that > having such a large timeout would be unbearable Suppose we have an inferior call as part of the breakpoint command conditions, and suppose that breakpoint is hit very frequently. What do we want to happen in this case? Do we want: . GDB to silently keep calling the inferior and waiting for it to time out? . GDB to announce the timeout and stop the first time it happens? . something else? I thought we wanted the 1st alternative, in which case waiting for a second could make the run very slow, since an inferior call should take, like, microseconds in almost all cases? But if we intend GDB to stop and not continue in this case, then yes, 1 sec could be appropriate. Or maybe I'm missing something regarding how this feature is supposed to be used?