From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Cr8zEa+udWDANQAAWB0awg (envelope-from ) for ; Tue, 13 Apr 2021 10:46:07 -0400 Received: by simark.ca (Postfix, from userid 112) id 3F1B31F104; Tue, 13 Apr 2021 10:46:07 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=MAILING_LIST_MULTI, RDNS_DYNAMIC autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 7EF0A1E01F for ; Tue, 13 Apr 2021 10:46:06 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 31D4839450EB; Tue, 13 Apr 2021 14:46:05 +0000 (GMT) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by sourceware.org (Postfix) with ESMTPS id 093783943541 for ; Tue, 13 Apr 2021 14:46:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 093783943541 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wr1-f42.google.com with SMTP id p6so10029585wrn.9 for ; Tue, 13 Apr 2021 07:46:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7n0iZyu5j7UY3PBtIPb+dR2FSgVKZt4+ALoteGUZKA0=; b=CVAuVedMNUp1wI+kHMUY1jWJAEcxcE+9izAoYNMGeSlytl9qjP2R9V55esdiCZWPkt lAab5u0LXLBvrXaW8RI/EKj7KOogF+KD3WcfZi6LyMRiemOGDez2SnP026kO1SLuXCyt tBXL6gZl0mdJGzvdnzXISSayY+2aR+uGqtckuD2P9uLgMSZ1SHfsAiXrvObyTIL01Eo5 D/WUdzMYUgzP8FYIB2M/SkfNSH9K3KLpd7pzGS3x6YClMO3Vw+nmDGQbvYG3oSxayUmx VzdT5LnS8JRZGvoWZk/mNnc9+28BUd2smQkzScqzXMXvag5inSlAVZNolXsYmezvWUjJ cwAQ== X-Gm-Message-State: AOAM5309D4Iw5r/KVQwNw2sjhw/kzC8cvCNLGwpIb+saq7jQZEF3Wdlr duy8S2xfYvCa1kUmg72mrxy27ynt6v17XcJc X-Google-Smtp-Source: ABdhPJy8HSUkkaYOrUBCr4ZDTvH1PjXm4vRjrz2oTuQIxmk6E29StoWlcsA6fFw1oqzVGjuG7CGBdw== X-Received: by 2002:a5d:6b82:: with SMTP id n2mr36660883wrx.399.1618325161407; Tue, 13 Apr 2021 07:46:01 -0700 (PDT) Received: from ?IPv6:2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3? ([2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3]) by smtp.gmail.com with ESMTPSA id h9sm2675320wmb.35.2021.04.13.07.45.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Apr 2021 07:46:00 -0700 (PDT) Subject: Re: [PATCH][gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32 From: Pedro Alves To: Luis Machado , Tom de Vries , gdb-patches@sourceware.org References: <20210118114422.GA11394@delia> <208b6e38-66f5-0395-62f7-9f122384a3a5@linaro.org> Message-ID: <500c8933-8d03-9cb0-fd4c-7ab1b3a35065@palves.net> Date: Tue, 13 Apr 2021 15:45:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <208b6e38-66f5-0395-62f7-9f122384a3a5@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 13/04/21 14:33, Luis Machado wrote: > > Forcing scheduler-locking to on made the output consistent for both cases, but I was left wondering if enabling scheduler-locking would cause the bug to not be reproducible anymore. Yeah, no. That would just paper over problems. GDB should cope with threads disappearing beneath it, as they're resumed, stopped, etc. Forcing scheduler-locking just means you're only resuming one thread instead of many, and thus reducing the chances of some GDB issue triggering. Wouldn't be much different from making the testcase be single-threaded. Pedro Alves