From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by sourceware.org (Postfix) with ESMTPS id 827EE3857C79 for ; Tue, 12 Jul 2022 17:14:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 827EE3857C79 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-wr1-f44.google.com with SMTP id h17so12145076wrx.0 for ; Tue, 12 Jul 2022 10:14:58 -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=e93rH5NG78kl8001q4H6daP1zItp1cDOyUUhTAhfDXY=; b=Y1QZSGIc0+P6qWji+FnmzXNE3h4yOErNdZyEX8ai8547cEvOyOWVpnbd33w50ImtY7 YZasUCsm7HiVmBMv+CDJXPtw4GymXrFuC95zj3fgQIQLU6Co5dLCGYqGG2pu1Ig4PuFV ckb+0AZlpDbsS0bv9Zj/Bsc5O2QqPiCPm2ueU1U8fX2ZMAw4E8NCHlunlOHea8h4gu/h nXfm7/+sMZkUZYmYG0DJvB31y35th6vy2zXRSDKNhlfMIqBiK8JnmiNyPH0456biB6K7 bGXsSHKZ8qeALNmn3P5KqdXYEbVH8lxRicJT6pjQ8vo99BOjFmm8RckT0iz1mPexz+B3 ijIQ== X-Gm-Message-State: AJIora+zsuP7FMoeCkT3a8LNjkPfCGe3iUi+m9MKyRG+5xJS3Gnx6V6j ch8tw34WypZ1OYDhGYfRhvWz/INBY9M= X-Google-Smtp-Source: AGRyM1tlQEVegRHHJsXL6tg2jMU9INkvM6UrwxS6PkoegYsYgFikE4U7wYNrvGS5pZ4y4BpgQUdiiA== X-Received: by 2002:a05:6000:144b:b0:21d:a57d:8000 with SMTP id v11-20020a056000144b00b0021da57d8000mr11925245wrx.204.1657646096183; Tue, 12 Jul 2022 10:14:56 -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 j16-20020a5d6050000000b0021db2dcd0aasm2416233wrt.108.2022.07.12.10.14.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 10:14:54 -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> <34fb9a8e-abb3-2331-a77e-b989d78249f5@palves.net> <83wnciwbxu.fsf@gnu.org> From: Pedro Alves Message-ID: Date: Tue, 12 Jul 2022 18:14:53 +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: <83wnciwbxu.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: Tue, 12 Jul 2022 17:15:00 -0000 On 2022-07-12 5:08 p.m., Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Mon, 11 Jul 2022 20:39:31 +0100 >> >> So all in all, how about the version below? > > It's fine, thanks. > Great, thanks. As mentioned before I'd do, I removed the new sentence about new threads, and pushed the resulting patch as a pure cleanup/improvement, as below. >From d21d919bc1d75f89140218f0d5702d0afff41209 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Tue, 30 Nov 2021 19:52:11 +0000 Subject: [PATCH] Improve "set scheduler-locking" documentation This improves the "set scheduler-locking" documentation in the GDB manual: - Use a table to describe the four available modes. - Describe "step" in terms of "on" and "off". - Tweak the "replay" mode's description to describe replay first instead of recording, and also mention how the mode behaves during normal execution. - Say what is the default mode. Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce --- gdb/doc/gdb.texinfo | 40 +++++++++++++++++++++++++++------------- 1 file changed, 27 insertions(+), 13 deletions(-) diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 562e4c1f628..9a8b010476a 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -6939,19 +6939,33 @@ 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. + +@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. base-commit: 3da5576c911a0f3fc608471f1486dc6db11052ef -- 2.36.0