From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by sourceware.org (Postfix) with ESMTPS id 42690385842F for ; Mon, 11 Jul 2022 17:48:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 42690385842F 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-f49.google.com with SMTP id bk26so7964409wrb.11 for ; Mon, 11 Jul 2022 10:48:23 -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=mj9S0fpPLEgKlTF5I/RiaF1IemzZScsL3HkkOIXBB4A=; b=3xDk+d+j3j81IpMdDOXuAy8NZ56PchsGEawshnIy248a/TZ3KWV7Z8yktHn0WvK4QB Ww68/ZEENhxZ5H+onxEfS7DTW2nAGX6Ir5Ljx8CWOQJ/411RiNnKl3KF0dIBToIysM6Q 079X087eAPJ3ctWcm5Vv98fT6CBwzsm5uahrEYyrcDXHmqPT/HeBNw/OuohUKfSuYUTG WGMN16R9vOU66MX+9DBmwnFEI33MoI70NgF9Ua4UvgKw29Sp6gRrPWrPc5dxdwYeCb/W tK6YW/A4uNkN2qGnYcsxkha+sh6aKsH5CKXMxP1jZe9HaWagcBxm2w4ZBznIv0IUtBMP GSJQ== X-Gm-Message-State: AJIora/vtDUaGMf0yLWNvJag/DX/3dkyZfjS9bDGRwKI2mHLoVfvWq36 D2+ypEQp7UgWVRMoUq8mW55rsuBRPF4= X-Google-Smtp-Source: AGRyM1sZnry4jtO3T4B6US4Nm0iJ+NVOVbtJG7mzYnh6C8Ge+jBBJ0qeFySUMjZfDJlHDRZE+mnHWw== X-Received: by 2002:adf:e483:0:b0:21d:a52e:261d with SMTP id i3-20020adfe483000000b0021da52e261dmr6522882wrm.228.1657561701164; Mon, 11 Jul 2022 10:48:21 -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 n31-20020a05600c501f00b003a2ebb087fbsm424804wmr.0.2022.07.11.10.48.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jul 2022 10:48:20 -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> From: Pedro Alves Message-ID: <65b0807a-67b2-04a0-c82e-09209d8fc176@palves.net> Date: Mon, 11 Jul 2022 18:48:19 +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: <83edyrzisp.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, 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=no 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 17:48:25 -0000 On 2022-07-11 6:00 p.m., Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Mon, 11 Jul 2022 17:38:48 +0100 >> >>> @item set scheduler-locking @var{mode} >>> @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; even threads >>> created by the resumed thread are held stopped. ^^^^^^^^^^^^ >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> And now I wonder what happens when scheduler-locking is set to 'step': >>> are new threads created by the resumed thread held stopped as in the >>> ON case? >>> >> >> Yes, they are. That's why I put the new sentence at the end and not connected to "on", >> and said "is in effect", not "on". I.e., when the scheduler is actually locked. > > But that is too far: it comes after you tell how the replay mode > behaves, which is a separate issue. So if you want to say it once for > both ON and STEP values, I suggest to say something like > > Both the @code{on} and @code{step} settings hold stopped any new > threads created by the resumed thread. > > before you describe how the rep[lay mode behaves. > I don't see it as a separate issue. The last sentence just before mine says: "The @code{replay} mode behaves like @code{off} in record mode and like @code{on} in replay mode." I.e., the scheduler is locked in replay mode. This is another case of scheduler-locking being in effect. This is exactly how GDB looks at things: /* Returns true if scheduler locking applies. STEP indicates whether we're about to do a step/next-like command to a thread. */ static bool schedlock_applies (struct thread_info *tp) { return (scheduler_mode == schedlock_on || (scheduler_mode == schedlock_step && tp->control.stepping_command) || (scheduler_mode == schedlock_replay && target_record_will_replay (minus_one_ptid, execution_direction))); }