From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kyhnCIXvumQPFCoAWB0awg (envelope-from ) for ; Fri, 21 Jul 2023 16:50:13 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=vYWX0zuO; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 14DC31E0BD; Fri, 21 Jul 2023 16:50:13 -0400 (EDT) Received: from server2.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 DF7011E00F for ; Fri, 21 Jul 2023 16:50:10 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B2A16385B53C for ; Fri, 21 Jul 2023 20:50:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B2A16385B53C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1689972608; bh=EE5r85foWJLOPX9PUXOOp312/L6+MioJtyceoojFYWU=; h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=vYWX0zuO0J4t4vjhvYbo3jzaMvDAE/MbhSze0p6UUvzFVErkvi5pz/Dh/gHoHnuxX Q1UQpgzp+q3jDdZ07JafhR9gwUoAH2rpJuBErTkLt9FVDTUPjYQQWGEXlwlSL1ciDu 4FfYtSoaS50/311xvh7/N9sM8NRKz9EK3vNMDKlk= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id CA686385B53C for ; Fri, 21 Jul 2023 20:49:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CA686385B53C Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-576-kGMVwzd-M--jeIFA5kKVoA-1; Fri, 21 Jul 2023 16:49:43 -0400 X-MC-Unique: kGMVwzd-M--jeIFA5kKVoA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0873E87323F; Fri, 21 Jul 2023 20:49:43 +0000 (UTC) Received: from f37-zws-nv (unknown [10.22.17.111]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 64AE42166B25; Fri, 21 Jul 2023 20:49:42 +0000 (UTC) Date: Fri, 21 Jul 2023 13:49:40 -0700 To: Cc: gdb-patches@sourceware.org, , Subject: Re: [PATCH] gdbserver: Install single-step breakpoint for a pending thread whose last_resume_kind is resume_step Message-ID: <20230721134940.1ee4be68@f37-zws-nv> In-Reply-To: <20230712032540.3110113-1-zhiyong.yan@windriver.com> References: <20230712032540.3110113-1-zhiyong.yan@windriver.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: , From: Kevin Buettner via Gdb-patches Reply-To: Kevin Buettner Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi Zhiyong, I set up a Raspberry Pi running a recent 32-bit Raspberry Pi OS so that I could test your patch. I was able to build and run your test case, but I could not reproduce the bug on the Pi. I tested gdb.threads/*.exp using --target_board=native-gdbserver both with and without your patch. Some of these tests are racy, but my conclusion from just looking at the PASSes and FAILs (after many test runs) is that there are no regressions. But then I remembered to enable core dumps on the Pi and after running gdb.threads/pending-fork-event-detach/pending-fork-event-detach-main-vfork by itself, I saw that it left a core file... $ make check RUNTESTFLAGS="--target_board=native-gdbserver" TESTS=gdb.threads/pending-fork-event-detach.exp ... === gdb Summary === # of unexpected core files 1 # of expected passes 240 The core file was from the running test case, not gdbserver, nor gdb. Looking at the core file in GDB shows... Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 0x00010624 in break_here () at /mesquite2/sourceware-git/rpi-gdbserver/bld/../../worktree-gdbserver/gdb/testsuite/gdb.threads/pending-fork-event-detach.c:29 29 x++; [Current thread is 1 (Thread 0xf7e10440 (LWP 4835))] (gdb) x/i $pc => 0x10624 : udf #16 (gdb) x/x $pc 0x10624 : 0xe7f001f0 ...and in gdbserver/linux-aarch32-low.cc: #define arm_eabi_breakpoint 0xe7f001f0UL I think what's happened here is that the breakpoint added by your patch is left in place when GDB detaches the test case. When it starts running again, it hits the software single step breakpoint and, since it's no longer under GDB control, it dies with a SIGTRAP. This core file is not created when I run the test using a gdbserver without your patch. I'm suspicious of the assert in linux_process_target::maybe_hw_step. Currently, it looks like this: bool linux_process_target::maybe_hw_step (thread_info *thread) { if (supports_hardware_single_step ()) return true; else { /* GDBserver must insert single-step breakpoint for software single step. */ gdb_assert (has_single_step_breakpoints (thread)); return false; } } But, when Yao Qi introduced it back in June, 2016, it looked like this: static int maybe_hw_step (struct thread_info *thread) { if (can_hardware_single_step ()) return 1; else { struct process_info *proc = get_thread_process (thread); /* GDBserver must insert reinsert breakpoint for software single step. */ gdb_assert (has_reinsert_breakpoints (proc)); return 0; } } So, back is 2016, when it was introduced, it's clear that the assert was referring to breakpoints which needed to be reinserted. Now, that's not at all obvious. Also, back in 2016, maybe_hw_step() was only called from two locations; in each case it was in a block in which the condition lwp->bp_reinsert != 0 was true. But now there are two other calls; in one case, the software single step breakpoints have just been inserted, so that should be okay, but for the other case, in linux_process_target::resume_stopped_resumed_lwps, I'm less certain. In any case, could you comment out (or delete) the assert in a version of the source without your patch and let me know what happens? Also, if possible, I'd like to see a backtrace from where the assert occurs so that I can see which call to maybe_hw_step is responsible for triggering the failing assert. Kevin