From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id lBulEvw1Y2oiNisAWB0awg (envelope-from ) for ; Fri, 24 Jul 2026 05:53:00 -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=W+L0eXD5; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 3ADB31E099; Fri, 24 Jul 2026 05:53:00 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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 autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 830E61E099 for ; Fri, 24 Jul 2026 05:52:59 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0DD294BA799D for ; Fri, 24 Jul 2026 09:52:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0DD294BA799D 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=W+L0eXD5 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 1014F4BA23F6 for ; Fri, 24 Jul 2026 09:52:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1014F4BA23F6 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 1014F4BA23F6 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784886752; cv=none; b=uL4z7KOElgYU24RrwGL7OjaVBQu3CzUd3f/w8kd+UIKOy1q9DketQ7TEbw3Ulqoe5NDOldrYhfXoLWwcq3q4pyS6TlCtcYxP2ltRy8+vETPt8IfNo3Wx7yTakoMoxwz6xTHWG53iNSmcPct7/MICZsyxScyfMNqf8yrdf+SgNf4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784886752; c=relaxed/simple; bh=8sHiiP4ntnxLKgP9CodprNzXOsjFAScS9HPf40uUSSI=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=QN4vu2h5QhDZepCddYTYPkGAc5ybjemwZVtDyHS4VTmU6Lz5B3q4HtPYmD4H/c9u7wK8WKIJfJaVJ6luuHKffbLmK/p4LAp2s/9CFKSrKAQxC+ETtyfULVhSTbY5pg2nwH6ojofa+2PnWuLLJtucphXJz5ziqlliEwJMqNcOxC0= ARC-Authentication-Results: i=1; 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=W+L0eXD5 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1014F4BA23F6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784886751; 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: in-reply-to:in-reply-to:references:references; bh=RZT/1nQMcsV3J9syihManJ+8tgpzYNlmIESLXT7+r3E=; b=W+L0eXD5TmDTPsjEPCh6XoIzvoTmHcbxgsZ6/isBQ2T6idPTFmd/mDjxDXx2keqYlOWC7S Rp5jP3IPoVmnGMeJJiFNlP8TVSPJubVqZh44OfKrnIh+Pb3lSuX+aygmiOSZid9DlUHor6 BxGyA7LGlXmThIp8G+38b7hAOnXRIQs= 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-15-OoTd2i3rMfCpDmULsL5mKg-1; Fri, 24 Jul 2026 05:52:28 -0400 X-MC-Unique: OoTd2i3rMfCpDmULsL5mKg-1 X-Mimecast-MFC-AGG-ID: OoTd2i3rMfCpDmULsL5mKg_1784886747 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-47f726186c4so179909f8f.2 for ; Fri, 24 Jul 2026 02:52:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784886747; x=1785491547; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=RZT/1nQMcsV3J9syihManJ+8tgpzYNlmIESLXT7+r3E=; b=c2Sp0kl8fS9LtbldlDEKLguvTtH3hKBaOSgYVdHsYhrcTm7kjDEXWgsYJ3TzfNTYRM Ao5BBBxzRvlEGVL47Wk86ab/H9DWo5g8RQ6Rq1QLkQ0oDXgqrTneCoXNQAZvbGkR/51K 8VS4UKIrCS0Z3E/+IZOU6B02IOWyyydjSiQE5ia4wXJ53/irbDycHuR5HYVXl9yfahTi rAfjgsOufg56tI9fxLiYo08nXs3RFJfGlicB6n0RCaw6r17KJiZvbNaPnoTEoxV4vA+/ 9SFayyqRyZAtKd184f9sgr/anVPd7DKuWBUkkXEIXWFYbHhJSuuQ3Mx8/b5DYPoW6qJc 0wyw== X-Forwarded-Encrypted: i=1; AHgh+Rr5PxcfgUh4SYreR0TmQ/G2DIwHirijVANq8pNCm5zf672A2kplw/bgLxBvPkCwxftNCMOEEyfq83S3tg==@sourceware.org X-Gm-Message-State: AOJu0YzkfvYDRsifpEU1ksLM8wg7JGGa0g866TS0A13Rq08E0/spOQoc Dn7C7KLhHSvxyh9s88tcjPpCqlsfZ/V1QB/XoxVdk7CTCxaegsslGIGdMJv1vgytDVjpAqlhtvv EjEXJ1vUReyXd6o9kMJOyY/5SLO5n4xt58MSJBQBnBBZ0VQeNIDSjtuN/K0/WHuk= X-Gm-Gg: AR+sD11xpgkAdjjtr7PVSp/B1mZ3mlig2JMZeRQt3upG1t/PZFz/q5EcJpSVFS2K/aF BaGoeoGvpVSYZqeHgW7DHSq4qZ5ejkUuBeoi9wZsbQwCvTs4CvT2m+0HqcMUPaMAwzw9Nk5Mkeh PNmvfjk7XONV2hrg3DSa6x9Zs3cfniibZdePqh9OZgjmOia7M+++exJ6ahvQf8frpeFYxN1xrp8 JdJXsUemwuYHqe1rwxDjERUGHTFEiwSND6yu0/qDEQZKSmmTY4184O7RQiA9945LkjODvp8Sr3h QxXJj1icjaVcD/cU7oRLmtDNnHGGfms/mE7Sk1kISWVVQ8DtlV8KM3joG8aReB3ogRomqPrK X-Received: by 2002:a05:6000:1867:b0:47f:810c:8abe with SMTP id ffacd0b85a97d-47f8dc7a0fcmr8648664f8f.36.1784886747224; Fri, 24 Jul 2026 02:52:27 -0700 (PDT) X-Received: by 2002:a05:6000:1867:b0:47f:810c:8abe with SMTP id ffacd0b85a97d-47f8dc7a0fcmr8648624f8f.36.1784886746643; Fri, 24 Jul 2026 02:52:26 -0700 (PDT) Received: from localhost ([31.111.209.233]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85b9a659sm23814473f8f.6.2026.07.24.02.52.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2026 02:52:25 -0700 (PDT) From: Andrew Burgess To: Klaus Gerlicher , gdb-patches@sourceware.org Cc: tom@tromey.com, guinevere@redhat.com, eliz@gnu.org Subject: Re: [PATCH v8 6/6] gdb: add eval option to lock the scheduler during infcalls. In-Reply-To: <20260722102746.131536-7-klaus.gerlicher@intel.com> References: <20260722102746.131536-1-klaus.gerlicher@intel.com> <20260722102746.131536-7-klaus.gerlicher@intel.com> Date: Fri, 24 Jul 2026 10:52:24 +0100 Message-ID: <87h5loogtj.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: YOgBBkLSuUnWGp2GmToZlIseSZGXXzTnP5qSkg_K1Kw_1784886747 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 Klaus Gerlicher writes: > From: Natalia Saiapova > > This patch adds an "eval" scheduler locking setting to control inferior > function calls separately from other continuing commands. > > "continue" handles continuing commands, such as continue, until, return, > finish, jump. > "eval" handles inferior calls. > > Show scheduler locking: > (gdb) show scheduler-locking > scheduler-locking continue: "off" Scheduler locking for continuing > commands is "off" during normal execution. > scheduler-locking eval: "off" Scheduler locking for function calls > is "off" during normal execution. > scheduler-locking replay continue: "on" Scheduler locking for > continuing commands is "on" during replay mode. > scheduler-locking replay eval: "on" Scheduler locking for function > calls is "on" during replay mode. > scheduler-locking replay step: "on" Scheduler locking for stepping > commands is "on" during replay mode. > scheduler-locking step: "off" Scheduler locking for stepping commands > is "off" during normal execution. > > Reviewed-By: Eli Zaretskii > --- > gdb/NEWS | 13 ++-- > gdb/doc/gdb.texinfo | 25 +++++--- > gdb/infrun.c | 61 +++++++++++++++---- > .../gdb.mi/user-selected-context-sync.exp | 3 +- > .../gdb.threads/hand-call-in-threads.exp | 6 +- > .../multiple-successive-infcall.exp | 5 +- > gdb/testsuite/gdb.threads/schedlock.exp | 41 ++++++++++--- > gdb/testsuite/lib/gdb.exp | 3 +- > 8 files changed, 118 insertions(+), 39 deletions(-) > > diff --git a/gdb/NEWS b/gdb/NEWS > index 30d0637518b..0a1f15c153e 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -905,15 +905,20 @@ list . > set scheduler-locking (on|off) > show scheduler-locking > where is one of the following: > - continue | replay continue | replay step | step. > - Extend the scheduler locking settings with a set of set/show > - commands, which can be used individually to control the scheduler during > - stepping and continuing commands. Stepping commands include step, stepi, > + continue | eval | replay continue | replay eval | replay step | step > + Extend the scheduler locking settings with a set of set/show commands, > + which can be used individually to control the scheduler during stepping, > + continuing and evaluating commands. Stepping commands include step, stepi, > next. Continuing commands include continue, finish, until, jump, return. > + The evaluating commands are those which invoke inferior calls. > 'continue' -- when on, the scheduler is locked during continuing commands > in normal mode. > + 'eval' -- when on, the scheduler is locked during inferior calls in > + normal mode. We need to be careful referencing "normal mode". With the context of this patch I understand you mean "not replay mode", but as a user approaching the NEWS file without the context of this patch, "normal mode" doesn't have much meaning. This comment also applies to the text for 'continue' which I didn't spot before. For 'eval' it would be nice to be more explicit, especially as this links to some confusion later in this patch. Inferior calls can be driven directly by the user, e.g. 'print some_user_function()' but can also be more indirect, e.g. 'break LOC if (some_user_function())'. In this second case the call can happen at some arbitrary time in the future. What are the expectations for the 'eval' setting in these two cases? > 'replay continue' -- when on, the scheduler is locked during continuing > commands in replay mode. > + 'replay eval' -- when on, the scheduler is locked during inferior calls > + in replay mode. > 'replay step' -- when on, the scheduler is locked during stepping > commands in replay mode. > 'step' -- when on, the scheduler is locked during stepping commands > diff --git a/gdb/infrun.c b/gdb/infrun.c > index b6f7721dbf3..7f390d7db25 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -2563,11 +2571,13 @@ show_schedlock_option (ui_file *file, int from_tty, > type = "stepping commands"; > else if (strcmp (c->name, "continue") == 0) > type = "continuing commands"; > + else if (strcmp (c->name, "eval") == 0) > + type = "function calls"; > else > gdb_assert_not_reached ("Unexpected command name."); > > gdb_printf (file, _("\"%s\" Scheduler locking for %s is " > - "\"%s\" during the %s.\n"), value, type, value, mode); > + "\"%s\" during %s.\n"), value, type, value, mode); Ah, that's why the text in the previous commit didn't match the code. We already discussed this text in the last commit, but whatever else happens, this fix shouldn't live here. > } > > /* True if execution commands resume all threads of all processes by > @@ -3410,13 +3420,20 @@ thread_still_needs_step_over (struct thread_info *tp) > > /* Return true if OPTS lock the scheduler. > STEP indicates whether a thread is about to step. > + While the stepping info we take from STEP argument, the inferior call > + state we get from the thread TP. > Note, this does not take into the account the mode (replay or > normal execution). */ > > static bool > -schedlock_applies_to_opts (const schedlock_options &opts, bool step) > +schedlock_applies_to_opts (const schedlock_options &opts, bool step, > + thread_info *tp) > { > - return ((opts.cont && !step) || (opts.step && step)); > + bool in_infcall = (tp != nullptr) && tp->control.in_infcall; > + > + return ((opts.cont && !step && !in_infcall) > + || (opts.step && step) We don't consider IN_INFCALL here. Does this trigger if we are stepping over a conditional breakpoint where the condition includes an inferior function call? What is the expected and actual behaviour here? Is this case tested? It seems like this change is worth discussing even if the code as written is correct, as it's surprising (at least to me). > + || (opts.eval && in_infcall)); > } > > /* Returns true if scheduler locking applies to TP. */ In a previous comment we discussed the schedlock_applies_to_opts call in clear_proceed_status. I was surprised that this doesn't now pass through the thread pointer. If it did then schedlock_applies_to_opts would no longer need to default the thread pointer to NULL. In fact, I would go as far as to say that even if passing NULL in that case is correct then schedlock_applies_to_op should remove the default argument value and clear_proceed_status should explicitly pass NULL and should gain a comment explaining why passing NULL is the correct solution. > diff --git a/gdb/testsuite/gdb.threads/schedlock.exp b/gdb/testsuite/gdb.threads/schedlock.exp > index cda4585ca08..58f8d9ae4de 100644 > --- a/gdb/testsuite/gdb.threads/schedlock.exp > +++ b/gdb/testsuite/gdb.threads/schedlock.exp > @@ -364,17 +365,39 @@ proc test_schedlock_opts {cont step} { > my_continue "continue" > check_result "continue" $curthread $cont_args $locked > } > + > + # Infcall tests. > + set locked 0 > + if {$eval eq "on"} { > + set locked 1 > + } > + with_test_prefix "cmd=infcall" { > + # Use whichever we stopped in. > + set curthread [get_current_thread "before-infcall"] > + set cont_args [get_args "before-infcall"] > + > + for {set i 0} {[expr $i < 10]} {set i [expr $i + 1]} { This should be: for { set i 0 } { $i < 10 } { incr i } { > + with_test_prefix "infcall #$i" { > + gdb_test "print some_function()" ".*" > + } > + } > + > + check_result "infcall" $curthread $cont_args $locked > + } > } > > gdb_test_no_output "set scheduler-locking off" > > # Test different options of scheduler locking. > foreach cont {"off" "on"} { > - foreach step {"off" "on"} { > - with_test_prefix "continue=$cont step=$step" { > - gdb_test_no_output "set scheduler-locking continue $cont" > - gdb_test_no_output "set scheduler-locking step $step" > - test_schedlock_opts $cont $step > + foreach eval {"off" "on"} { > + foreach step {"off" "on"} { > + with_test_prefix "continue=$cont eval=$eval step=$step" { > + gdb_test_no_output "set scheduler-locking continue $cont" > + gdb_test_no_output "set scheduler-locking eval $eval" > + gdb_test_no_output "set scheduler-locking step $step" > + test_schedlock_opts $cont $eval $step > + } > } > } > } Thanks, Andrew