From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id BC6573858C60 for ; Sun, 26 Sep 2021 22:43:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BC6573858C60 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id CEE971FF1F; Sun, 26 Sep 2021 22:43:58 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B769B13B13; Sun, 26 Sep 2021 22:43:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id uF96K673UGFzGgAAMHmgww (envelope-from ); Sun, 26 Sep 2021 22:43:58 +0000 Subject: Re: [PATCH] gdb.threads/process-dies-while-detaching: disable with software watchpoint To: Lancelot SIX Cc: "gdb-patches@sourceware.org" References: <20210921202403.2536496-1-lsix@lancelotsix.com> <36b3309b-ed0a-5248-d47b-351e480345fc@suse.de> <20210922214023.5pymq32j4kqhq34x@ubuntu.lan> <20210926171149.dyqkyt66dzzpi5rj@ubuntu.lan> From: Tom de Vries Message-ID: <3a7ce0a1-51cd-a7d6-c73d-7d2f97971ff7@suse.de> Date: Mon, 27 Sep 2021 00:43:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210926171149.dyqkyt66dzzpi5rj@ubuntu.lan> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Sun, 26 Sep 2021 22:44:01 -0000 On 9/26/21 7:11 PM, Lancelot SIX wrote: > On Sun, Sep 26, 2021 at 11:54:02AM +0200, Tom de Vries wrote: >> On 9/22/21 11:40 PM, Lancelot SIX wrote: >>> Hi, >>> >>> I had a look at your patch, it is for sure a better approach than mine. >>> >>> At some point you change the order between the 'continue_to_exit_bp' and >>> 'watch' commands when forcing software watchpoint. Any reason not to >>> use the same order for both cases? >>> >> >> Yes, because sw watchpoints are slow. > > I mean I totally understand why it makes sense to move the 'watch' > command after continue_to_exit_bp when using software watchpoints. The > question was more is there a reason not to do the same for hardware > watchpoints? Yes, the fact that the existing test-case comments in detail about that order for hardware watchpoints. I don't want to break the existing test-case. > I do not expect any 'gain' from doing the same with > hardware assisted watchpoint except having something similar in both > cases. > >> >>> (gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: watch globalvar >>> continue >>> Continuing. >>> [Thread 0x3fea68a150 (LWP 2358916) exited] >>> [...] >>> [Thread 0x3ff7ea5150 (LWP 2358889) exited] >>> KFAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue (timeout) (PRMS: gdb/28375) >>> >>> This does not look like what you reported in PR28375. I guess the >>> setup_kfail should be adjusted to account for the two way this test can >>> fail (I am not sure if they both come down to the same problem or not). >>> >> >> Is there a gdb prompt inbetween the PASS and KFAIL? > > No. In the snippet I provided above, the '[...]' skips a bunch of > '[Thread 0xXXXXXXXXXX (LWP XXXXXXX) exited] ', and nothing else. > Ack, thanks for clarifying this. > Looking into this I fixed an omission in the RISC-V prologue analyzer for which > I plan in submitting a patch later when I have found time to write a testcase > for it. With this being fixed, the log for > gdb.threads/process-dies-while-detaching.exp becomes: > > watch globalvar > Watchpoint 3: globalvar > (gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: watch globalvar > continue > Continuing. > Cannot access memory at address 0x3ff7f2e324 > (gdb) KFAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue (PRMS: gdb/28375) > UNSUPPORTED: gdb.threads/process-dies-while-detaching.exp: single-process: continue: hw watchpoint > Ok, then perhaps the KFAIL doesn't need an update. > I’ll continue to work on this when possible. > Great. I'll commit the version I posted, unless there other objections. Thanks, - Tom