From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ADfaKnrN0GTjGDoAWB0awg (envelope-from ) for ; Mon, 07 Aug 2023 06:54:50 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=windriver.com header.i=@windriver.com header.a=rsa-sha256 header.s=PPS06212021 header.b=anAEwv6V; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AB4661E0BB; Mon, 7 Aug 2023 06:54:50 -0400 (EDT) Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 910631E028 for ; Mon, 7 Aug 2023 06:54:48 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 209BB3858418 for ; Mon, 7 Aug 2023 10:54:48 +0000 (GMT) Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by sourceware.org (Postfix) with ESMTPS id 235D83858412 for ; Mon, 7 Aug 2023 10:54:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 235D83858412 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=windriver.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=windriver.com Received: from pps.filterd (m0250811.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.17.1.22/8.17.1.22) with ESMTP id 377AK2Rr003325; Mon, 7 Aug 2023 10:54:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=windriver.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:content-transfer-encoding:mime-version; s= PPS06212021; bh=UQTkH+6o4y3TwBZV8cqBt1/kQlrcPeMJAeEoDI7B1pU=; b= anAEwv6VCBjxjK1LzDp+v/QDXh9wBprHbE81v7uqAf3h7clAxXh8Pk9GcTtXXdJ0 wx3/MRWmuNkjXZ+8+6m6jHkHWSJhJuv+IVuhRliPYpAB+MJknK2S9SKF7I7Y6Fbe prO56U2es6PfbExInXmbrwUTGB6lRsR03h6E1bOXe+apMw9c/wz2GZ/eo6/93jaM /ahOc8LXxfPt9WxEP8U0Ei3wF8bdYqPZT3vltFu9VoiZpWgEGfISqAlxlHfSHTKl 6zxpgLMB+a8NuXYFvc9jlnEPIpyCoEvb8JNV9JspI9wghhDCoPzLP8yoo5Js1kK+ CQ7dptgIHiF2h/u67EJ1sw== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2106.outbound.protection.outlook.com [104.47.58.106]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 3s9bmx1jfq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Aug 2023 10:54:19 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ecMdg3u2jqJ+ufYBrzH1nC9SThOfzfXtApQKBNYliNQgoVdimhS2q3Mz57vG0zzCLQZY5Ztkz0kpYTqZXqJX5zluLWStIZwVUNYPHsLQVDCj9qtwQ/1O7qGP4nNiVNyvMWWgK4ZHEigeh6+XIEW3vpcJiOVGtapK4fGzCY+fP3OC674bgLHp4+NVQd23XmMi/Ko+j2V1WOA111AjKQccjdQ310bi0cBxw2lNmmjJgzORDzKPZKXTjiIafFhGKFJC3GTsdT88nd8Iw41IupX/FDZn/AFCtEPjm/sufuqq/ukZ0RjPEdYZ78TkWWUdr9AVZMeVEaCrZvmAhPmWKfPJxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UQTkH+6o4y3TwBZV8cqBt1/kQlrcPeMJAeEoDI7B1pU=; b=bGRGseZeq/ylWnZX6LLOpGgyEy0xDWIQF4athPkTOqYqQoQjytyf1vEKRjSyF5fIUhZAJFAIvP+Fn5TjBgCzPC/mf/sFXaZErcoDd3qYNA4/il7BvG90N9zeNxcW0Jo1NWerJ18159poVAy85P0aHFJhgfUkRV3r5CE9z+F3bJzBxMKXDHHe6txGaplVJDkkZHfn1dB88RM5gLkMcPDG3A2N24iMDaNSocjsvYINklCeMdqXMdb+pA7xrmwWvrv4AmeXfvxP9dNHQ6xpqf9YiNgLGwgrxjkEYwJ3aZTjjIergNqWfRvSeK6bArjiv88BQMxwh9Nm32MurXBhmXM9CQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from DS0PR11MB6447.namprd11.prod.outlook.com (2603:10b6:8:c4::16) by MW3PR11MB4683.namprd11.prod.outlook.com (2603:10b6:303:5c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6652.26; Mon, 7 Aug 2023 10:54:16 +0000 Received: from DS0PR11MB6447.namprd11.prod.outlook.com ([fe80::f7e4:b822:8ebc:36fc]) by DS0PR11MB6447.namprd11.prod.outlook.com ([fe80::f7e4:b822:8ebc:36fc%4]) with mapi id 15.20.6652.026; Mon, 7 Aug 2023 10:54:16 +0000 From: "Yan, Zhiyong" To: Kevin Buettner , "gdb-patches@sourceware.org" CC: "simon.marchi@polymtl.ca" Subject: RE: [PATCH 1/1] gdbserver: Reinstall software single-step breakpoints in resume_stopped_resumed_lwps Thread-Topic: [PATCH 1/1] gdbserver: Reinstall software single-step breakpoints in resume_stopped_resumed_lwps Thread-Index: AQHZxaeVtMfkD3ZaCkyWUvFIx3Ic5q/erkMQ Date: Mon, 7 Aug 2023 10:54:16 +0000 Message-ID: References: <20230803011146.2093194-1-kevinb@redhat.com> <20230803011146.2093194-2-kevinb@redhat.com> In-Reply-To: <20230803011146.2093194-2-kevinb@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS0PR11MB6447:EE_|MW3PR11MB4683:EE_ x-ms-office365-filtering-correlation-id: c67f2f03-83cf-4878-9c6f-08db9734a4e9 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QaNUC1aQ1LRw1R/4KVS8v9jONkramEiWBuNqZK6N7iA5c+mdMzk0BhEbGR8t2OZo02tLaM9tUb2WNkA5onwA01ciCTD84IJGcFvaj9zUvgwiy7gvWeoB6Ssd03gybt13ffY8WyUnHLzTdLBnZKJ8/mAc1zGxozq6dG9uZF/BZ+KIliAlpRUcVe2Z7JPJc4O01+oZ+RDA7jXkVtiUUIVVCTxAp9QeKgwWGhdgxS+6lMEUNdBro7dKVmIbYU6zsYzGAMPcCtiohJgh1sofavuRlctzWHhPLqbmORySXcUedx6kht1dUwae9bvnUYZNR4WRF5/KufQ3D75Sj1qhtruKR3Osp3J/iHbpWO2N0zcTtOQ4xrABdBeeTmdu5ZWR2noixLdhNbK6t8PhR9DNznJhDbWxNin27SMrLABvRpkO5oE/0pV1p/BYGToVK3Mgp0ItaJN3ZXj5qLCR1QZJgZ63cNo2glgjVAfxB9M5oXS5W582GxSdtM2E08oxYNaoQUXAVLnlcZnZaYx1cCW/KEJ1bn/x7byknx5EAcqQQWGE0RrYH2V/rmbrbg3CL3mLwJwQ3Fn4fhSxiMrXG7o2bP1VEg2cDbXhi76Pg1y8gOPxD3dVWK5EkfOE+Hz+uQj8LKzgMxtDeOgqehFh22tfQRoQVr/RYYMi9SOjdLCGn37gfpU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB6447.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(39850400004)(366004)(376002)(346002)(136003)(396003)(1800799003)(186006)(451199021)(52536014)(38070700005)(41300700001)(26005)(30864003)(2906002)(5660300002)(83380400001)(8676002)(66899021)(84970400001)(8936002)(55016003)(122000001)(86362001)(316002)(33656002)(6506007)(53546011)(7696005)(76116006)(110136005)(38100700002)(66556008)(64756008)(66446008)(66476007)(71200400001)(66946007)(478600001)(9686003)(966005)(4326008)(2004002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?6ythFL21mkY8ksRhUzEemkmG5UlwR4ZT8m6jnxIofry2zsclh2CIED/G/Nxd?= =?us-ascii?Q?Rh2GKk1FIzHrs/wSAQROJ/E5PREqVE6EBW5FOOQPs4KpTn74Go4dMltTpfp5?= =?us-ascii?Q?+fJo37cO8b1nQgzKJIJdwPUAe4M3V/AySj2ELegMaSBtNjCwzr+c0VZSiFeY?= =?us-ascii?Q?ZHZq2msMmeoAWxwA5DI/AlQcPFqSmtwgWqD+sXYk9/TRk+yyDe/gOq5idGmO?= =?us-ascii?Q?RwiKI71gz/Ww4W8p54VV/R5WZadqnvDp3+V+3Img8SnLN0nIGIcRGTBwRjxZ?= =?us-ascii?Q?TxqbD6/gDXLQcoiapN06qsce96BSK+sqRQocAgvgmCZXjJuJ7+Nt/m95w/oL?= =?us-ascii?Q?peQShcPvEJ9LmF89FRQohF7pyx1nWEbYv1YAulYDRAP9TH0SXZfKs/y3bY3w?= =?us-ascii?Q?2DP24s034Cym8j1pmdVnxw2tZURTkUKqsW7LvDsGk9OAiw7NIIWojB997Atp?= =?us-ascii?Q?ONx04UPFlXmJ3nixTuhqNwzi1+Gi8J5ROQpUTPV8HeignnjXpR5KIcq41Zyg?= =?us-ascii?Q?LXRIn1mH/v5YIOaEKuK6KTbyfsdhk0BmR0cCBshZ9+5VimS3+TlOWc3aZJJ+?= =?us-ascii?Q?SX+wSlwt7O75wQGFQFDJNp3WAYZogQGdQX7Kq6+xvdkV2JmUUH+t0HZWka6C?= =?us-ascii?Q?jFVj9JG0XRI7Ce1qKk/QyOaiKSp2FaYQRBqNbxqyLA7jgA5wO9YXlW43eXqH?= =?us-ascii?Q?zzo7gnW6pDIdiCNjiyGalou7CQJi8UFzGcGu567WuoefpfH7ssQVfRo+Eug5?= =?us-ascii?Q?3ov5aLRx+O7QU3LC3KBI5pnVg7Pzhl/MFb4KBvA46ZtSU13A2ZArloaYDuYo?= =?us-ascii?Q?r/nSLwkj+OxDFp/NFcOTJq6p8cRcf+umRsi3/Wt2zj4CS00IS0fqbA7VQ1vp?= =?us-ascii?Q?UW2exqn5zhh6xv07Cx3pNrD0XGrDz5r1DRzjiDVrF8MdWfn9kPPzwU+XY8ij?= =?us-ascii?Q?K71Qv+OfSOTFN0lxJGw4ysnJFPEqn4FgiWyFRG+nVVxHpWxAqJUXqziUMpfw?= =?us-ascii?Q?fASnyO21Pxgpvabn+t+uG+8bzfcxPdcEu+y8eHT+C2KQDd9DSKxrZ1OlUap/?= =?us-ascii?Q?Z41GKsiGKt5p/QaZinjXTp/qa9CCt5yClOukywpkjjC3Kg9hkXja7o1kc6h1?= =?us-ascii?Q?iXzJQee2gAwDu+jrlp2sHg1d5GgnpvVj6UEtxs+wIH/2oDalFk9TX1tdam0g?= =?us-ascii?Q?O5YiKNt6gvPaR6MFNCnECEPR7ii0zBngz6TbniMWgWgTd6LPMFZeBAVzEa+/?= =?us-ascii?Q?WTBO6fgCmGnSPJKOqrfqTEx5Lj7/bdqxhj865z06Sh3UuHU0jvWVg0OnIgKW?= =?us-ascii?Q?KR8dmY1k/L7e8TzSd/Mf4kqFzIR/oeVdjxx2MZSYvNTi/ntt5ahkaEuhj63d?= =?us-ascii?Q?CFBFE+asyXjEv04dYVXztzlVEfT6JYu9uuqhNEN/OnUcDn3j6x6ia/rWwNdj?= =?us-ascii?Q?W+3AMYna8Iu05OhCo7xGjtuTfyzdRiCxtHBG4qPgDqmCwu/4pDj7DQUw3m3l?= =?us-ascii?Q?7l0XTSx0xPSQh1RhR4zsPf+618pSacdjSxytJmM4P2UP8SpzFCdD8+mlG8RP?= =?us-ascii?Q?EGEROPtBYDLz41+TyOTO0EAVP1klXvd4lhTP7eys?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB6447.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c67f2f03-83cf-4878-9c6f-08db9734a4e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2023 10:54:16.3909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pLXyYB3YaPYgPLhzGEzt05D48zPjCscce4T9Jq0US/eDfSROUuT6JlbKMuA7mgskYxKc5HTNoBz65kuQ7NDBoTuxmsYNIgFBdvaDTOmSRyw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4683 X-Proofpoint-ORIG-GUID: yQ2Yr7bSNrhM4ct07GAUbIweiw-Tzy8z X-Proofpoint-GUID: yQ2Yr7bSNrhM4ct07GAUbIweiw-Tzy8z X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-08-07_09,2023-08-03_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 lowpriorityscore=0 phishscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 bulkscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2306200000 definitions=main-2308070100 X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP 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: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi Kevin, Today I backport below patch to gdb 13.0.5 which is used by our custom= er board. I verify this patch by customer's app where the assert error was first= ly reported, and verify it by test app "osm". This patch can fix the assert error in my tests. Best Regards. Zhiyong -----Original Message----- From: Kevin Buettner =20 Sent: Thursday, August 3, 2023 8:56 AM To: gdb-patches@sourceware.org Cc: Yan, Zhiyong ; simon.marchi@polymtl.ca; Kevi= n Buettner Subject: [PATCH 1/1] gdbserver: Reinstall software single-step breakpoints = in resume_stopped_resumed_lwps CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and = know the content is safe. At the moment, while performing a software single-step, gdbserver fails to = reinsert software single-step breakpoints for a LWP when interrupted by a s= ignal in another thread. This commit fixes this problem by reinstalling so= ftware single-step breakpoints in linux_process_target::resume_stopped_resu= med_lwps in gdbserver/linux-low.cc. This bug was discovered due to a failing assert in maybe_hw_step() in gdbse= rver/linux-low.cc. Looking at the backtrace revealed that the caller was l= inux_process_target::resume_stopped_resumed_lwps. I was uncertain whether the assert should still be valid when called from t= hat method, so I tried hoisting the assert from maybe_hw_step to all caller= s except resume_stopped_resumed_lwps. But running the new test case, descr= ibed below, showed that merely eliminating the assert for this case was NOT= a good fix - a study of the log file for the test showed that the single-s= tep operation failed to occur. Instead GDB (via gdbserver) stopped at the next breakpoint that was hit. Zhiyong Yan had proposed a fix which resinserted software single-step break= points, albeit at a different location in linux-low.cc. Testing revealed t= hat, while running gdb.threads/pending-fork-event-detach, the executable associated with that test would die due to a SIGTRAP after t= he test program was detached. Examination of the core file(s) showed that = a breakpoint instruction had been left in program memory. Test results were otherwise very good, so Zhiyong was definitely on the rig= ht track! This commit causes software single-step breakpoint(s) to be inserted before= the call to maybe_hw_step in resume_stopped_resumed_lwps. This will cause= 'has_single_step_breakpoints (thread)' to be true, so that the assert in m= aybe_hw_step... /* GDBserver must insert single-step breakpoint for software single step. */ gdb_assert (has_single_step_breakpoints (thread)); ...will no longer fail. And better still, the single-step breakpoints are = reinstalled, so that stepping will actually work, even when interrupted. The C code for the test case was loosely adapted from the reproducer provid= ed in Zhiyong's bug report for this problem. The .exp file was copied from= next-fork-other-thread.exp and then tweaked slightly. As noted in a comme= nt in next-fork-exec-other-thread.exp, I had to remove "on" from the loop f= or non-stop as it was failing on all architectures (including x86-64) that = I tested. I have a feeling that it ought to work, but this can be investig= ated separately and (re)enabled once it works. I also increased the number= of iterations for the loop running the "next" commands. I've had some tes= t runs which don't show the bug until the loop counter exceeded 100 iterati= ons. The C file for the new test uses shorter delays than next-fork-other-= thread.c though, so it doesn't take overly long (IMO) to run this new test. Running the new test on a Raspberry Pi w/ a 32-bit (Arm) kernel and userlan= d using a gdbserver build without the fix in this commit shows the followin= g results: FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dfork: target= -non-stop=3Dauto: non-stop=3Doff: displaced-stepping=3Dauto: i=3D12: next t= o other line FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dfork: target= -non-stop=3Dauto: non-stop=3Doff: displaced-stepping=3Don: i=3D9: next to o= ther line FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dfork: target= -non-stop=3Dauto: non-stop=3Doff: displaced-stepping=3Doff: i=3D18: next to= other line FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dfork: target= -non-stop=3Doff: non-stop=3Doff: displaced-stepping=3Dauto: i=3D3: next to = other line FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dfork: target= -non-stop=3Doff: non-stop=3Doff: displaced-stepping=3Don: i=3D11: next to o= ther line FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dfork: target= -non-stop=3Doff: non-stop=3Doff: displaced-stepping=3Doff: i=3D1: next to o= ther line FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dvfork: targe= t-non-stop=3Dauto: non-stop=3Doff: displaced-stepping=3Dauto: i=3D1: next t= o break here FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dvfork: targe= t-non-stop=3Dauto: non-stop=3Doff: displaced-stepping=3Don: i=3D3: next to = break here FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dvfork: targe= t-non-stop=3Dauto: non-stop=3Doff: displaced-stepping=3Doff: i=3D1: next to= break here FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dvfork: targe= t-non-stop=3Don: non-stop=3Doff: displaced-stepping=3Dauto: i=3D47: next to= other line FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dvfork: targe= t-non-stop=3Don: non-stop=3Doff: displaced-stepping=3Don: i=3D57: next to o= ther line FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dvfork: targe= t-non-stop=3Doff: non-stop=3Doff: displaced-stepping=3Dauto: i=3D1: next to= break here FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dvfork: targe= t-non-stop=3Doff: non-stop=3Doff: displaced-stepping=3Don: i=3D10: next to = break here FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dvfork: targe= t-non-stop=3Doff: non-stop=3Doff: displaced-stepping=3Doff: i=3D1: next to = break here =3D=3D=3D gdb Summary =3D=3D=3D # of unexpected core files 12 # of expected passes 3011 # of unexpected failures 14 Each of the 12 core files were caused by the failed assertion in maybe_hw_s= tep in linux-low.c. These correspond to 12 of the unexpected failures. When the tests are run using a gdbserver build which includes the fix in th= is commit, the results are significantly better, but not perfect: FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dvfork: targe= t-non-stop=3Don: non-stop=3Doff: displaced-stepping=3Dauto: i=3D143: next t= o other line FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=3Dvfork: targe= t-non-stop=3Don: non-stop=3Doff: displaced-stepping=3Don: i=3D25: next to o= ther line =3D=3D=3D gdb Summary =3D=3D=3D # of expected passes 10178 # of unexpected failures 2 (I think that the two remaining failures are due to some different problem.= And, FWIW, I don't see these failures on the Pi when using --target_board=3Dnative-extended-gdbserver.) Running the new test on x86-64 and aarch64, both native and native-gdbserve= r shows no failures. Also, I see no regressions when running the entire test suite for armv7l-un= known-linux-gnueabihf (i.e. the Raspberry Pi w/ 32-bit kernel+userland) with --target_board=3Dnative-gdbserver. Additionally, using --target_board=3Dnative-gdbserver, I also see no regressions for the = entire test suite for x86-64 and aarch64 running Fedora 38. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30387 Co-Authored-By: Zhiyong Yan --- .../gdb.threads/next-fork-exec-other-thread.c | 82 +++++++++++ .../next-fork-exec-other-thread.exp | 131 ++++++++++++++++++ gdbserver/linux-low.cc | 7 +- 3 files changed, 219 insertions(+), 1 deletion(-) create mode 100644 gdb/= testsuite/gdb.threads/next-fork-exec-other-thread.c create mode 100644 gdb/testsuite/gdb.threads/next-fork-exec-other-thread.e= xp diff --git a/gdb/testsuite/gdb.threads/next-fork-exec-other-thread.c b/gdb/= testsuite/gdb.threads/next-fork-exec-other-thread.c new file mode 100644 index 00000000000..884706c6c3c --- /dev/null +++ b/gdb/testsuite/gdb.threads/next-fork-exec-other-thread.c @@ -0,0 +1,82 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2023 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see=20 + . */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define MAX_LOOP_ITER 10000 + +static char *argv0; + +static void* +worker_a (void *pArg) +{ + int iter =3D 0; + char *args[] =3D {argv0, "self-call", NULL }; + + while (iter++ < MAX_LOOP_ITER) + { + pid_t pid =3D FORK_FUNC (); + if (pid =3D=3D 0) + { + /* child */ + if (execvp (args[0], args) =3D=3D -1) + { + fprintf (stderr, "execvp error: %d\n", errno); + exit (1); + } + } + + waitpid (pid, NULL, 0); + usleep (5); + } +} + +static void* +worker_b (void *pArg) +{ + int iter =3D 0; + while (iter++ < MAX_LOOP_ITER) /* for loop */ + { + usleep (5); /* break here */ + usleep (5); /* other line */ + } +} + +int +main (int argc, char **argv) +{ + pthread_t wa_pid; + pthread_t wb_pid; + + argv0 =3D argv[0]; + + if (argc > 1 && strcmp (argv[1], "self-call") =3D=3D 0) + exit (0); + + pthread_create (&wa_pid, NULL, worker_a, NULL); pthread_create=20 + (&wb_pid, NULL, worker_b, NULL); pthread_join (wa_pid, NULL); + + exit (0); +} diff --git a/gdb/testsuite/gdb.threads/next-fork-exec-other-thread.exp b/gd= b/testsuite/gdb.threads/next-fork-exec-other-thread.exp new file mode 100644 index 00000000000..e4d6ff53ded --- /dev/null +++ b/gdb/testsuite/gdb.threads/next-fork-exec-other-thread.exp @@ -0,0 +1,131 @@ +# Copyright 2022-2023 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify=20 +# it under the terms of the GNU General Public License as published by=20 +# the Free Software Foundation; either version 3 of the License, or #=20 +(at your option) any later version. +# +# This program is distributed in the hope that it will be useful, # but=20 +WITHOUT ANY WARRANTY; without even the implied warranty of #=20 +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU=20 +General Public License for more details. +# +# You should have received a copy of the GNU General Public License #=20 +along with this program. If not, see . + +# This test was adapted from next-fork-other-thread.exp. The .c file #=20 +was adapted from the reproducer for this bug: +# +# https://sourceware.org/bugzilla/show_bug.cgi?id=3D30387# +# +# That bug demonstrates a problem with software-singlestep in gdbserver. +# Prior to being fixed, this test also demonstrated that bug for a #=20 +32-bit ARM target. (Use=20 +RUNTESTFLAGS=3D"--target_board=3Dnative-gdbserver".) +# It has been reproduced on a Raspberry Pi running Ubunutu server #=20 +20.04.5 LTS with 32-bit kernel + 32-bit userland. It was NOT=20 +reproducible # using a circa 2023 Raspberry Pi OS w/ 64-bit kernel and 32-= bit userland. + +standard_testfile + +# Line where to stop the main thread. +set break_here_line [gdb_get_line_number "break here"] + +# Build executables, one for each fork flavor. +foreach_with_prefix fork_func {fork vfork} { + set opts [list debug pthreads additional_flags=3D-DFORK_FUNC=3D${fork_= func}] + if { [build_executable "failed to prepare" \ + ${testfile}-${fork_func} ${srcfile} $opts] } { + return + } +} + +# If testing against GDBserver, consume all it its output. + +proc drain_gdbserver_output { } { + if { [info exists ::server_spawn_id] } { + gdb_test_multiple "" "" { + -i "$::server_spawn_id" + -timeout 0 + -re ".+" { + exp_continue + } + } + } +} + +# Run the test with the given parameters: +# +# - FORK_FUNC: fork flavor, "fork" or "vfork". +# - TARGET-NON-STOP: "maintenance set target-non-stop" value, "auto", "o= n" or +# "off". +# - NON-STOP: "set non-stop" value, "on" or "off". +# - DISPLACED-STEPPING: "set displaced-stepping" value, "auto", "on" or = "off". + +proc do_test { fork_func target-non-stop non-stop displaced-stepping } { + save_vars { ::GDBFLAGS } { + append ::GDBFLAGS " -ex \"maintenance set target-non-stop ${target-= non-stop}\"" + append ::GDBFLAGS " -ex \"set non-stop ${non-stop}\"" + clean_restart ${::binfile}-${fork_func} + } + + gdb_test_no_output "set displaced-stepping ${displaced-stepping}" + + if { ![runto_main] } { + return + } + + # The "Detached after (v)fork" messages get in the way in non-stop, di= sable + # them. + gdb_test_no_output "set print inferior-events off" + + # Advance the next-ing thread to the point where we'll execute the nex= ts. + # Leave the breakpoint in: it will force GDB to step over it while nex= t-ing, + # which exercises some additional code paths. + gdb_test "break $::break_here_line" "Breakpoint $::decimal at $::hex.*= " + gdb_test "continue" "hit Breakpoint $::decimal, worker_b.*" + + # Next an arbitrary number of times over the lines of the loop. + for { set i 0 } { $i < 200 } { incr i } { + # If testing against GDBserver, the forking threads cause a lot of + # "Detaching from process XYZ" messages to appear. If we don't con= sume + # that output, GDBserver eventually blocks on a full stderr. Drain= it + # once every loop. It may not be needed for 20 iterations, but it'= s + # needed if you increase to 200 iterations. + drain_gdbserver_output + + with_test_prefix "i=3D$i" { + if { [gdb_test "next" "other line.*" "next to other line"] !=3D= 0 } { + return + } + + if { [gdb_test "next" "for loop.*" "next to for loop"] !=3D 0 }= { + return + } + + if { [gdb_test "next" "break here.*" "next to break here"] !=3D= 0} { + return + } + } + } +} + +foreach_with_prefix fork_func {fork vfork} { + foreach_with_prefix target-non-stop {auto on off} { + # This file was copied from next-fork-other-thread.exp and + # then adapted for the a case which also involves an exec in + # addition to the fork. Ideally, we should test non-stop "on" + # in addition to "off", but, for this test, that results in a + # number of failures occur preceded by the message: + # + # Cannot execute this command while the selected thread is running. + # + # That seems like correct behavior to me, but perhaps the + # non-stop case can be made to work; if so, simply add "on" + # after "off" on the line below... + foreach_with_prefix non-stop {off} { + foreach_with_prefix displaced-stepping {auto on off} { + do_test ${fork_func} ${target-non-stop} ${non-stop} ${displ= aced-stepping} + } + } + } +} diff --git a/gdbserver/linux-low.cc b/gdbserver/linux-low.cc index 651f219b= 738..e1806ade82f 100644 --- a/gdbserver/linux-low.cc +++ b/gdbserver/linux-low.cc @@ -2463,7 +2463,12 @@ linux_process_target::resume_stopped_resumed_lwps (t= hread_info *thread) int step =3D 0; if (thread->last_resume_kind =3D=3D resume_step) - step =3D maybe_hw_step (thread); + { + if (supports_software_single_step ()) + install_software_single_step_breakpoints (lp); + + step =3D maybe_hw_step (thread); + } threads_debug_printf ("resuming stopped-resumed LWP %s at %s: step= =3D%d", target_pid_to_str (ptid_of (thread)).c_str (), -- 2.41.0