From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id EBB3838543A4 for ; Fri, 13 Jan 2023 16:49:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EBB3838543A4 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673628584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cKwH9LwLwluv9/zDbRatu93ZcSnYd3ubltX4tnbZJ0M=; b=cMY80NuAVU1T43YL5r2C9zxd5NEHBHjNHOM2dyJ3dPGk2mfQb+OcxEYISMpGI7dRiKRK6V TdhrfDG5U3s3CanTtQTeb00mZTFO7p4RUxeGA10RgudZrnp+BSuOoXrJD5uVxvV7CBzkqD 3fqbrz6/P4HdgfFXNqLecouWdPf0TR4= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-79-CLXPW4vtOsqvJG-WhobSsA-1; Fri, 13 Jan 2023 11:49:39 -0500 X-MC-Unique: CLXPW4vtOsqvJG-WhobSsA-1 Received: by mail-wm1-f70.google.com with SMTP id bi18-20020a05600c3d9200b003d991844dbcso14471588wmb.4 for ; Fri, 13 Jan 2023 08:49:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cKwH9LwLwluv9/zDbRatu93ZcSnYd3ubltX4tnbZJ0M=; b=J9P2jTFrHpudwpMZp/znFIHSulo6msCjW0IjxOdMmG8U2/MJy78BntM/VzHI4XaLD7 kEROWUZ8qFRd8sm2Kj2MPEL1etCdL6qS1l1hQ2f7F9SGyYUb8dyOhyORNh/U9nPTdHSv kIUZ4LcPVzOOnyrUZYKmwUDaINgpZKtYE+V9UkiPFrR5YJOaUQWV1lo1Ncgr+iMtMOoC IJV5m3VQl8wUlml80nmu9XWv9iIplqS4NPZiVgcURFAm/zGIomIwj54z98uFwhK+zX5e sjLcFmy7rFsof/7QKjV4Vua8mD8O+sbn7ndjD+RKlQ4DI1eBSkgxn/9DIv7pxu4hZhwu Lv1Q== X-Gm-Message-State: AFqh2krqDyRvfWOnZGJUSJgy+mQvMdXsaiVruD8NaGYYbU1wNdXqwIrp v3R8kSFFTPfkH/c0poDzkIbhzAerDcVsLeAofVpERC8BJ7/4LyF7c9hPnAwF5Kca0eSQDQhXi/T luciAoI0Jv3Y0zCZ/qabyFg== X-Received: by 2002:a05:600c:3c93:b0:3d9:ed30:79d with SMTP id bg19-20020a05600c3c9300b003d9ed30079dmr16647845wmb.18.1673628575531; Fri, 13 Jan 2023 08:49:35 -0800 (PST) X-Google-Smtp-Source: AMrXdXurF4l1h0T6zAaKBct7jSeJsMR4vH428dD7fmIe2tBRIDlADQPXAm2u4iC3ZqdXY1FYAFyyzA== X-Received: by 2002:a05:600c:3c93:b0:3d9:ed30:79d with SMTP id bg19-20020a05600c3c9300b003d9ed30079dmr16647837wmb.18.1673628575380; Fri, 13 Jan 2023 08:49:35 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id h19-20020a05600c351300b003d9a86a13bfsm27797311wmq.28.2023.01.13.08.49.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Jan 2023 08:49:34 -0800 (PST) From: Andrew Burgess To: Lancelot SIX Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 11/12] gdb: add timeouts for inferior function calls In-Reply-To: <20221104231700.evhnzbuwexevh2hd@ubuntu.lan> References: <20221104231700.evhnzbuwexevh2hd@ubuntu.lan> Date: Fri, 13 Jan 2023 16:49:34 +0000 Message-ID: <87mt6mfkgx.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Lancelot SIX writes: > 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. >>=20 >> 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. >>=20 >> 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. >>=20 > > I do see the use of the indirect call timeouts, and I=E2=80=AFfind it a g= ood > 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. That was indeed why I provided both - it pretty much came for free. Like you say, it might offer some benefits in a GDB scripting setup. If you feel really strongly then I can drop it, but I don't feel it adds much additional maintenance overhead. Thanks, Andrew