From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kBmeEILY91/LHgAAWB0awg (envelope-from ) for ; Thu, 07 Jan 2021 22:58:58 -0500 Received: by simark.ca (Postfix, from userid 112) id 30F751E965; Thu, 7 Jan 2021 22:58:58 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.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 3E3C51E519; Thu, 7 Jan 2021 22:58:57 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8EBED3971C07; Fri, 8 Jan 2021 03:58:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8EBED3971C07 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610078336; bh=eOEa9bFJYIPK4igQz93i/AoWfFrOLTJ9gN0XZcc3jCE=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=fBoHcLmT+kOr01F2dfqB+uke1eO3l7cYdj0RhWtOOaP2otK75bK7slgEfxDXTyrgP TgwcPeAfeEFjSUjYSLOGCvz1fhNw8vTd6ngS7C6VDsyXQ2zvzkSuS80v630oqnBIxZ 9nOw3ds1e8awBsmdcF0wTKDuZfBtuYpPVuASm2Oo= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id C2E7C3971C07 for ; Fri, 8 Jan 2021 03:58:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C2E7C3971C07 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 1083wkQV030873 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Jan 2021 22:58:51 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 1083wkQV030873 Received: from [10.0.0.213] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 7103C1E519; Thu, 7 Jan 2021 22:58:46 -0500 (EST) Subject: Re: [PATCH] gdb: better handling of 'S' packets To: Pedro Alves , Andrew Burgess , gdb-patches@sourceware.org References: <20201111153548.1364526-1-andrew.burgess@embecosm.com> Message-ID: Date: Thu, 7 Jan 2021 22:58:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 8 Jan 2021 03:58:46 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-01-07 7:51 p.m., Pedro Alves wrote: >> + >> + gdb_breakpoint "unlock_worker" >> + gdb_continue_to_breakpoint "run to unlock_worker" >> + >> + # There should be two threads at this point with thread 1 selected. >> + gdb_test "info threads" \ >> + "\\\* 1\[\t \]*Thread\[^\r\n\]*\r\n 2\[\t \]*Thread\[^\r\n\]*" \ >> + "second thread should now exist" >> + >> + # Switch threads. >> + gdb_test "thread 2" ".*" "switch to second thread" >> + >> + # Single step. This will set all threads running but as there's >> + # no reason for the first thread to report a stop we expect to >> + # finish the step with thread 2 still selected. > > I think GDB will first switch to thread 1 to step over the breakpoint thread 1 > is stopped at and only after will it step thread 2 while letting thread 1 run free. > I think that with your patch GDB will do the "right" thing and figure out the > right thread for the first step stop of thread 1 correctly, since at that point > no other thread is executing. It's just that the comment seems a bit off. > v2 uses scheduler-locking, I suppose to address that. >> + gdb_test_multiple "stepi" "" { >> + -re "Thread 1 received signal SIGTRAP" { > > Shouldn't this consume the prompt? Is it important? We could probably just omit it and let gdb_test_multiple time out if it doesn't see what we expect? > >> + fail $gdb_test_name >> + } >> + -re "$hex.*$decimal.*while \\(worker_blocked\\).*$gdb_prompt" { >> + pass $gdb_test_name >> + } >> + } >> + >> + # Double check that thread 2 is still selected. >> + gdb_test "info threads" \ >> + " 1\[\t \]*Thread\[^\r\n\]*\r\n\\\* 2\[\t \]*Thread\[^\r\n\]*" \ >> + "second thread should still be selected after stepi" >> + >> + # Now "continue" thread 2. Again there's no reason for thread 1 >> + # to report a stop so we should finish with thread 2 still >> + # selected. > > Ditto here. This also changed in v2, the test now lets both threads and the program run until the end. I tried to address all your comments that still apply in the version I'll send. Simon