From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by sourceware.org (Postfix) with ESMTPS id 9F8103858D1E for ; Mon, 11 Jul 2022 19:39:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9F8103858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f46.google.com with SMTP id be14-20020a05600c1e8e00b003a04a458c54so3610810wmb.3 for ; Mon, 11 Jul 2022 12:39:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PL94OO6eclYlfp6d7j6GDoXcinUfPjM1WqJaGVKO38k=; b=MTJB4rxdnc37C6FRrhezzMZpsjHVbUQA4RGmjKwyt1oWNapxvzqhgVjvZrm5D/Xw3k IQoJWlYbF/u+fVdkkMmNURExFRb9W0QoUfUXMutCbLXYvmCQGLGWHRS2XQGP/+K5kMI1 uSBtn4hdElZmytcqqimLa8FXwYQpPMySztmqtlK1aX+OspPGShkIASmbweM+v46xjfev aP0isxoW/tA6UgRGZwPl2WGdwK6qsEMtPCOfvnMunAuJ71qwnQMlEb+JiDVAIDySf2+X 2OJF2j80HjMjiYS+l9Iz7475bNIwaergcg4ohRbWtywZCuTmeyfEMPbLsyf4S0YERbP9 ejpg== X-Gm-Message-State: AJIora86xXoRw4cvWlveqr6rTw1vckrG+lFaf7e3appnW0XjzRbnyOrH LhFb2E4dqDZOtGOTPmFFaVjg6UdGx2g= X-Google-Smtp-Source: AGRyM1tCUiBxsfQmAR7DmdO0tlsYhYmBPq1Hs5Rzr8qfO11nBYtu/tYFFCz8f5sPgRAaMZ4tmIruNg== X-Received: by 2002:a1c:f60f:0:b0:3a0:3e0c:1de1 with SMTP id w15-20020a1cf60f000000b003a03e0c1de1mr17817864wmc.56.1657568373850; Mon, 11 Jul 2022 12:39:33 -0700 (PDT) Received: from ?IPv6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id m22-20020a7bcb96000000b003a2cf5eb900sm5010412wmi.40.2022.07.11.12.39.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jul 2022 12:39:32 -0700 (PDT) Subject: Re: [PATCH 19/25] Don't resume new threads if scheduler-locking is in effect To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20220620225419.382221-1-pedro@palves.net> <20220620225419.382221-20-pedro@palves.net> <83a6a6l1fk.fsf@gnu.org> <72ce23b7-6e3c-b867-6d96-9df93fba5cfb@palves.net> <83mtdfzma7.fsf@gnu.org> <83h73nzk59.fsf@gnu.org> <891ff735-3153-787e-cd6c-621180bf341b@palves.net> <83edyrzisp.fsf@gnu.org> <65b0807a-67b2-04a0-c82e-09209d8fc176@palves.net> <834jznzgfw.fsf@gnu.org> <335857f3-f319-0bca-a964-c31a3f5ab449@palves.net> <8335f7zenk.fsf@gnu.org> From: Pedro Alves Message-ID: <34fb9a8e-abb3-2331-a77e-b989d78249f5@palves.net> Date: Mon, 11 Jul 2022 20:39:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <8335f7zenk.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 11 Jul 2022 19:39:37 -0000 On 2022-07-11 7:29 p.m., Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Mon, 11 Jul 2022 19:18:56 +0100 >> >>> Fine, but is something wrong with the text I proposed? >>> >> >> Yes, you said to put it before the description of how the replay mode behaves, >> and your text implies the change only affects "on" and "step", while it >> affects "replay" as well. As I said, the change affects all cases of >> actually locking the scheduler, so it is not appropriate to single out just >> some modes. > > But "replay" behaves either as "on" or as "off", and the effect of > "on" on new threads is covered by the text I proposed. So I don't see > the problem with it being before the description of "replay". > > The advantage of my proposal is that it doesn't interrupt the > continuity of the description of how "on" and "step" affect the > threads created by the single thread being resumed. The description > of "replay" is an interruption. > I can see that, but putting it just before replay is described is just one small sentence before, i.e., before "The @code{replay} mode behaves like @code{off} in record mode and like @code{on} in replay mode." one, and I have trouble seeing how that doesn't break the flow in the same way. Also, what you suggested: "Both the @code{on} and @code{step} settings hold stopped any new threads created by the resumed thread." has another problem -- it is incorrect for "step", for it implies that with "set scheduler-locking step", new threads are always held stopped, when they are only held stopped if you step; they won't be held stopped if you "continue" instead, for example. So if we take this "behave like on" approach, then it seems better to move the new sentence even earlier, right where "on" is described, and then tweak the "step" mode to say "behaves like on" too. And then, the more I stare at this whole modes description, with 4 different modes already (and there was a proposal to add one more some time ago), the more it seems to me like it would be better to redo it using a table. While at it, I think the "replay" mode's description is a bit backwards (should describe replay mode first instead of record mode), and it also fails to mention how the mode behaves during normal execution. Also, we miss saying what is the default mode... So all in all, how about the version below? If OK, I should perhaps put the manual (not NEWS) changes in immediately without the "New threads created by the resumed thread are also held stopped." sentence, as a pure clarification/rewording patch. I'm going to post a v2 of the series soon, and in that version, the manual change would then only be one added sentence to the "on" mode, about the new threads. diff --git a/gdb/NEWS b/gdb/NEWS index 742f4fe47fb..f0f6990dc59 100644 --- a/gdb/NEWS +++ b/gdb/NEWS @@ -3,6 +3,13 @@ *** Changes since GDB 12 +* Scheduler-locking and new threads + + When scheduler-locking is in effect, only the current thread may run + when the inferior is resumed. However, previously, new threads + created by the resumed thread would still be able to run free. Now, + they are held stopped. + * "info breakpoints" now displays enabled breakpoint locations of disabled breakpoints as in the "y-" state. For example: diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 562e4c1f628..77524095480 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -6939,19 +6939,34 @@ locking the OS scheduler to allow only a single thread to run. @cindex scheduler locking mode @cindex lock scheduler Set the scheduler locking mode. It applies to normal execution, -record mode, and replay mode. If it is @code{off}, then there is no -locking and any thread may run at any time. If @code{on}, then only -the current thread may run when the inferior is resumed. The -@code{step} mode optimizes for single-stepping; it prevents other -threads from preempting the current thread while you are stepping, so -that the focus of debugging does not change unexpectedly. Other -threads never get a chance to run when you step, and they are -completely free to run when you use commands like @samp{continue}, -@samp{until}, or @samp{finish}. However, unless another thread hits a -breakpoint during its timeslice, @value{GDBN} does not change the -current thread away from the thread that you are debugging. The -@code{replay} mode behaves like @code{off} in record mode and like -@code{on} in replay mode. +record mode, and replay mode. @var{mode} can be one of +the following: + +@table @code +@item off +There is no locking and any thread may run at any time. + +@item on +Only the current thread may run when the inferior is resumed. New +threads created by the resumed thread are also held stopped. + +@item step +Behaves like @code{on} when stepping, and @code{off} otherwise. +Threads other than the current never get a chance to run when you +step, and they are completely free to run when you use commands like +@samp{continue}, @samp{until}, or @samp{finish}. + +This mode optimizes for single-stepping; it prevents other threads +from preempting the current thread while you are stepping, so that the +focus of debugging does not change unexpectedly. However, unless +another thread hits a breakpoint during its timeslice, @value{GDBN} +does not change the current thread away from the thread that you are +debugging. + +@item replay +Behaves like @code{on} in replay mode, and @code{off} in either record +mode or during normal execution. This is the default mode. +@end table @item show scheduler-locking Display the current scheduler locking mode.