From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by sourceware.org (Postfix) with ESMTPS id E5C083858C5F for ; Tue, 25 Jul 2023 06:50:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E5C083858C5F 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 (m0250812.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.17.1.22/8.17.1.22) with ESMTP id 36P5EiCb002646; Tue, 25 Jul 2023 06:50:51 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=ErsNahYCpPiu5LKWHOOOdgCxZCXk7JcV+DErVpIuSdU=; b= JvXcYoXeEUQS1gGxfj0JFi+beoxVsz/wzGa1XRvsxWUmUaD8myHZT2kgmfhmIpXU Cj6wTsI31wd+iqBVjnmGMcsi/hOHHzpFAHoSXJCrXxOSbzbfmATFjis/ubv56S4c JMhpjFYcCKt9OYg6FEKepX/+wwG4y78ugA7wRNEm4FCqZ5uxWwTvFBBt5nzJzzgd VZ/ioPAPgGfjsYxDsjS5TZp1kiUgXPkHL2GXUb6+8kphWGvDj5FxNmt10uKuruRG +fLsnaLdwKEgTFRzT7Mme+0+rBvtMD5jX5PrJWHizdxLCCtvSRgT/Um3kKKcNDev Vny/GN8bLDzG9aQ9g2whbA== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2172.outbound.protection.outlook.com [104.47.57.172]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 3s0636a7fa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jul 2023 06:50:50 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZPijBm9YcRNGv/ooeumUDdqP3KkZyeg7Jsz2sGscQAca6t9exgUthFbU+RN7Tm8kfhMp1I8R7QlX/dAos0uZbA9bdKoDUMgro/RInAEYDcbrDpxHusI5SiNHg8770h/5mvEJA1XwtM9fXE0TWiq0DJFtUK/0DIIwb8vPmXyKTioVn0pVwD2Zi6gtUchB2PfXG5dtb7dR3ws2prHREkP5wCyZl9+XMipH7q9uc6fkgP8PoEMiLpwDX70BWo6EO+b+MARtX/fNbKLTn/rWRqsZc+0/o9staEHsEOor4Xd07R+AaJwm5svjKDit4LUYnSXS7mgtiJB7ZWT1rhSDWq2I9A== 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=ErsNahYCpPiu5LKWHOOOdgCxZCXk7JcV+DErVpIuSdU=; b=JRiOvT314zWdVzZfMEdQorKe31D8Ph/laMRi8N5TB2bJCOto7SiDtrCdf6wlE4qT5afNaHSQY2wa3QF7pLcLa8ohsMy7hNh10ljRjwDCUY3zNV4Wyv9UrFJ8F2HQJX6DWJ6mmEKqRKayxlNZqBX8EoD48T0Gq4rpoWgG3iZ/N67Ia7H74nbSIF7wTavLsM67oVR7OoRNl3ig94C9zQ0NB2tE50wntFn24dzrcE/qB2wRNMIiUlCJcycjcvD7SV5Six6UEwx9R49qe9h9AD/iyWpk2GDW2jbuUZ86rN17XtmzJWQOifP8xS6mmcd+QXzuw1idHsJOMrA4TnNeX5nvjQ== 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 SA0PR11MB4752.namprd11.prod.outlook.com (2603:10b6:806:99::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6609.33; Tue, 25 Jul 2023 06:50:35 +0000 Received: from DS0PR11MB6447.namprd11.prod.outlook.com ([fe80::ac37:b984:6529:cf0c]) by DS0PR11MB6447.namprd11.prod.outlook.com ([fe80::ac37:b984:6529:cf0c%7]) with mapi id 15.20.6609.032; Tue, 25 Jul 2023 06:50:35 +0000 From: "Yan, Zhiyong" To: Kevin Buettner CC: "gdb-patches@sourceware.org" , "luis.machado@arm.com" , "tom@tromey.com" Subject: RE: [PATCH] gdbserver: Install single-step breakpoint for a pending thread whose last_resume_kind is resume_step Thread-Topic: [PATCH] gdbserver: Install single-step breakpoint for a pending thread whose last_resume_kind is resume_step Thread-Index: AQHZvBTkPI/ep58SA0WKR0O2Y70Dha/I7Y0wgADsxwCAAAm8QIAAJz2AgAACReA= Date: Tue, 25 Jul 2023 06:50:35 +0000 Message-ID: References: <20230712032540.3110113-1-zhiyong.yan@windriver.com> <20230721134940.1ee4be68@f37-zws-nv> <20230724203650.43ddd754@f37-zws-nv> <20230724233207.59d9bca1@f37-zws-nv> In-Reply-To: <20230724233207.59d9bca1@f37-zws-nv> 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_|SA0PR11MB4752:EE_ x-ms-office365-filtering-correlation-id: ff95170b-ccda-4a3a-ddab-08db8cdb72c9 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OpOSNxE2At6QvrOtvY+wyNtWbA/cvmXG2FwJlT7uKNVa1QNU4WB/3nZSzC86WibsJuSqoBFe/aB6gaWA8trW00keLNQP2rIdLn4oyIfTOjU82PVoHiBw1rOyjiSrdYeLaVh938tm38gw8kfbNiuZME2zwysCtJKJxYI2rdlw6Mkqujes31V4lTNueNKV2E0mcRjWkZb9kBqQfughgICKIszrYPPZ8Xnvw4uf0s+XbSu/BfeoQQfgTlJIP721dmPIjLg9AGdNNL0eNw0u3KI3m+5tOnqBcFjaRs/sI58gKbat4WtjCK1Njj7ogdGt8IYyyNrBP2K+omt//57hReg4ji3OanNKX8xEqc20RXfhqfL57qUzsPOoFAs4YmVloVPowjs2d/17KYCjV/CxRrlcUAWCyJOGZV0wiDWGPPtSGe0jdotXkA8OpIpBaMfDzAKRGaytAUSo5vUQRpkUllqSaheBngqePNdJI0VshTykLqFNqLZGC22hMQ0Jzn5HvFRomu0gWjhSr1Ohirq5PrEKSudcmy+pDExCmqJIUWzlxwWsx9T6FZhJKkUmFRW0LrRnjme9MFsGHv4UE/bWRm5SpilvUnGTxZmYjjSBGWIrG2s= 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)(136003)(396003)(376002)(39850400004)(366004)(346002)(451199021)(54906003)(66476007)(66556008)(66946007)(76116006)(64756008)(66446008)(55016003)(83380400001)(86362001)(38070700005)(33656002)(122000001)(38100700002)(478600001)(186003)(7696005)(9686003)(53546011)(71200400001)(26005)(966005)(6506007)(2906002)(30864003)(41300700001)(5660300002)(316002)(4326008)(6916009)(84970400001)(52536014)(8676002)(8936002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?+2UuztOl95RQ7MLw4YxWNsGo1+nnAGsu/2V9U66TpDeL/yPhEdasYJ338Ek7?= =?us-ascii?Q?L1RvcCK3r3Zi+LJ2qJ+ydJ/BUlEG6Q/ZIu6/sWD+O9vE8OxINouDE8ELWJB5?= =?us-ascii?Q?iIjuUWUbOD1C3QevhDDcz7UV50LWhUtbkX/xQhR5GjCbyONxWSfIBSN0juSg?= =?us-ascii?Q?k+0kDoG6AEkbJa1FbUTZz2YYkfBK3ZglIKLCIfW3vyw4+qr28m/BgbOzP4kV?= =?us-ascii?Q?Bjb6fjmwVStqVWu6Yq5Pbe1iAHMPVScMpGJO5AwlSCb++vEvxj9Kb41jiezE?= =?us-ascii?Q?OKuhrHosPN2OjlkR1CDPaLFnuxtC057p7RaQ/mkruSfeqfRtvhrkGnWoB2xZ?= =?us-ascii?Q?fFXteJML46D8QaJX673PYjg9/Hoyo7nlhwJ6fGRi6g8QSqB5zD4F9lrioIls?= =?us-ascii?Q?0hg45VM3gJ3Dvk9guz3ypz5woUr5fPpruu80ew6EywYVPqIkzp52srqnGjQw?= =?us-ascii?Q?DSGWoXTNj9iicid7goYSUVLPeFLkZYUKnqdUKykoGcYM3TFLa1XixahZ4fQl?= =?us-ascii?Q?7p5AOaLh9gQmDSAmkfgieH1T1bOE0T6qGGb3Y4Ou0USixu0/PdziKBcfNa5G?= =?us-ascii?Q?gamgH2KK+I28i3Oj+oQnndeSRvfbE4CRBz5pk7BQoB0kQrAaac0w7dtKjVfV?= =?us-ascii?Q?dbxBeFkYq6UeL97g+NU76m/0294G9E7RmYQ4cWwdrrRKAVn6K5cSWs3OZqs1?= =?us-ascii?Q?1+ymIbvZIdqBy318dM4n7CrHaI5Rhdbs0lGWWhF6jgmmAmoK+Lne+8pXZH1L?= =?us-ascii?Q?ViR8Zd4LzBFlJtc3Q5x/4XC4IS7jpCnubzCZaFe2kVE+qsaqNyWN1qbNGbfp?= =?us-ascii?Q?gmbB0v52i8AuizIgMENPBBMPY0iVtct5ewYn/lBI9VEtmS8KHvae1WA0H85B?= =?us-ascii?Q?55IwlutX+LI1iuf5t/Qgm9CIGEdyhzk4XDmdgpvdAClLj1SkMRJA4BKszl6t?= =?us-ascii?Q?oBMuSPn55hFLVA35uqdv6sRiwxpT2Yo34S66g2SsWoUJpGaEvl0jmFrmRYDE?= =?us-ascii?Q?0BXXIDllfeDGo0ljeMgVa90fNWayprefolzkn4kV6ITFxHGVrsF5sXhYUori?= =?us-ascii?Q?Ab/YfAV8KivvdfhUh0tI5U7MfW7Kp9iSPQjOQL3++LzO2/Jopm7xGawazPbM?= =?us-ascii?Q?GrD0V+awp+WIykZVT40qoId+ZXUfks4cirhPA6b+DtZRxkmLCw98LPbLCKWO?= =?us-ascii?Q?DpnuqO7jm+g5gxGGhtk/KTSma7dSezQfbdmMaRHavbAXZJMkgbvz55KOHgwX?= =?us-ascii?Q?n3TsIt9ZiFrSymNZYo5pvfwCImlTkLYXc8J1iPmjenBV2k280izeP7pDHMXe?= =?us-ascii?Q?xvUebfL6mnjtEoqxk3650bjcupQCMgFbn84wh4kuceiq872MqE4Ioe701AJI?= =?us-ascii?Q?bouUfB7E63gURirMLoatLBtCUwr/xlGi1/2DAzqlZPZ47coa57e/rd4jahF4?= =?us-ascii?Q?5I0rJxXwAThSR6ebRL1+1ulO53hzECxcnJuJjm3AlPvNDCqhxtWVfOogQiwX?= =?us-ascii?Q?G0je+Rqui8/rNggg69ebz1wNcQUgF6mRo5Fb5qj95IT5lGvYhwe1ccfYGdUn?= =?us-ascii?Q?n6M7OdYWEmvIX6CsC0OauQA5Zh6HR1/t+oFqOgyT?= 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: ff95170b-ccda-4a3a-ddab-08db8cdb72c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2023 06:50:35.4574 (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: NJvIBv47igfMrGRnVSsyfDyJts0fTzy2vSprnLOi8peQepeL7Ri9zGmuRMc3zFIBz+GahWBl+cjI+Npl+sjY9YUmujb94R7202us42vDiEk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4752 X-Proofpoint-GUID: geq_c3xD0GMxDYJH6q_5caRfhunMpo7D X-Proofpoint-ORIG-GUID: geq_c3xD0GMxDYJH6q_5caRfhunMpo7D 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-07-25_02,2023-07-24_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 clxscore=1015 mlxscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2306200000 definitions=main-2307250061 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Kevin, Below is my PI's info: root@bcm-2xxx-rpi4:~# uname -a Linux bcm-2xxx-rpi4 5.15.110-yocto-standard #1 SMP PREEMPT Wed May 3 01:43:= 11 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux root@bcm-2xxx-rpi4:~# file gdbserver gdbserver: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (GNU/Linux= ), dynamically linked, interpreter /lib64/ld-linux-aarch64.so.1, BuildID[sh= a1]=3D1e6ee58be0809d620fbdf3f86c8c4541f01ad9e9, for GNU/Linux 3.14.0, with = debug_info, not stripped root@bcm-2xxx-rpi4:~# file osm osm: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamica= lly linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=3Dda7ee15= aec73080ae3954d803b542bd9e8185c44, for GNU/Linux 3.14.0, with debug_info, n= ot stripped root@bcm-2xxx-rpi4:~# Both user app and OS are aarch64.=20 [zyan1] On this, gdbserver supports hardware single step, assert doesn't ha= ppen. ----------------------------------------------------------- Below is my Xilinx-zynq info:=20 Last login: Wed Jul 26 03:03:09 2023 root@xilinx-zynq:~# uname -a Linux xilinx-zynq 5.15.106-yocto-standard #1 SMP PREEMPT Tue Apr 11 03:06:1= 0 UTC 2023 armv7l armv7l armv7l GNU/Linux root@xilinx-zynq:~# which ls /bin/ls root@xilinx-zynq:~# file /bin/ls /bin/ls: symbolic link to /bin/ls.coreutils root@xilinx-zynq:~# file /bin/ls.coreutils /bin/ls.coreutils: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYS= V), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]= =3Df8bf6bdad65965d53cdd9fd1ebfd00d191f4cbbc, for GNU/Linux 3.2.0, stripped root@xilinx-zynq:~# [zyan1] On this, gdbserver doesn't support hardware single step, assert can= happen. Best Regards. -----Original Message----- From: Kevin Buettner =20 Sent: Tuesday, July 25, 2023 2:32 PM To: Yan, Zhiyong Cc: gdb-patches@sourceware.org; luis.machado@arm.com; tom@tromey.com Subject: Re: [PATCH] gdbserver: Install single-step breakpoint for a pendin= g thread whose last_resume_kind is resume_step 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. Hi Zhiyong, One problem that I encountered on my Pi, which may explain the behavior tha= t you're seeing, is that recent 32-bit versions of the Raspberry Pi OS are = running a 64-bit/aarch64 kernel, but the userland is 32-bit. root@rpi4-2:~# /usr/bin/uname -m aarch64 root@rpi4-2:~# file /usr/bin/ls /usr/bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynami= cally linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=3D81004d0= 65160807541b79235b23eea0e00a2d44e, for GNU/Linux 3.2.0, stripped Note that uname -m returns aarch64, but that "ls" and other executables are= "ELF 32-bit ...". The binutils-gdb configury uses uname -m to figure out for what gdbserver h= ost/target to build. (host and target must be the same, otherwise gdbserve= r won't build.) So it may be the case that you built an aarch64 gdbserver i= nstead of an arm gdbserver. I think you can check this as follows: kev@rpi4-2:/mesquite2/sourceware-git/rpi-master/bld/gdbserver$ ls linux-{ar= m,aarch}* linux-aarch32-low.o linux-aarch32-tdesc.o linux-arm-low.o linu= x-arm-tdesc.o If you also/instead see linux-aarch64-low.o and linux-aarch64-tdesc.o in th= at list, then you probably have an aarch64 gdbserver. When I tried my build with uname -m returning aarch64, the build errored ou= t because (I think) I was missing certain aarch64 header files. But I knew= that I didn't want to build for aarch64, so I abandoned that build. What = I ended up doing was making a wrapper for uname which substituted 'arm' for= 'aarch64'. I put it in /usr/local/bin, and /usr/local/bin is early in my = PATH, so the configury finds it first... root@rpi4-2:~# uname -m arm Here's my /usr/local/bin/uname script: - - - - root@rpi4-2:~# cat /usr/local/bin/uname #!/bin/bash /usr/bin/uname $* | sed -e s/aarch64/arm/ - - - - [ Yes, this is a hack, but I couldn't think of a cleaner way to do it. I tried a configure line with "--host=3Darm-linux --target=3Dhost-linux", but that didn't work because something in the build wanted arm-linux-ar to exist and it didn't. I could have made some symlinks, e.g. "ln -s /usr/bin/ar /usr/local/bin/arm-linux-ar", with similar symlinks for gcc, g++, ln, ranlib, etc, but that seemed like more work than my uname wrapper hack.] I just checked my gdbserver build. It's definitely getting into arm_target::supports_hardware_single_step: Breakpoint 1, linux_process_target::maybe_hw_step ( this=3D0x8645c , thread=3D0x9df38) at /mesquite2/sourceware-git/rpi-master/bld/../../worktree-gdbserver/gd= bserver/linux-low.cc:2442 2442 if (supports_hardware_single_step ()) (gdb) s arm_target::supports_hardware_single_step (this=3D0x8645c ) at /mesquite2/sourceware-git/rpi-master/bld/../../worktree-gdbserver/gd= bserver/linux-arm-low.cc:1042 1042 return false; Kevin On Tue, 25 Jul 2023 04:21:00 +0000 "Yan, Zhiyong" wrote: > Hi Kevin, > I test gdb11 on RaspBerry Pi4. > As you said, I can't produce this assert issue. > The direct reason is because supports_hardware_single_step () return= s on RaspBerry Pi4, not like xilinux-zynq. > Please see attached pictures, we can see arm_target::supports_hardwa= re_single_step () is never entered. > This assert only happens when supports_hardware_single_step () retur= ns 'false'. On Raspberry Pi4, when I hardcoded supports_hardware_single_ste= p () returns 'false', then assert happened. > For more information about " This assert only happens when supports_= hardware_single_step () returns 'false'". > You can check=20 > https://sourceware.org/bugzilla/show_bug.cgi?id=3D30387 > > So, the new question is why arm_target::supports_hardware_single_ste= p () is never entered on Raspberry Pi4. > > Best Regards. > Zhiyong > > > -----Original Message-----, > From: Kevin Buettner > Sent: Tuesday, July 25, 2023 11:37 AM > To: Yan, Zhiyong > Cc: gdb-patches@sourceware.org; luis.machado@arm.com; tom@tromey.com > Subject: Re: [PATCH] gdbserver: Install single-step breakpoint for a=20 > pending thread whose last_resume_kind is resume_step > > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender an= d know the content is safe. > > Hi Zhiyong, > > I looked at the backtrace that you provided and see that=20 > maybe_hw_step() is being called from=20 > linux_process_target::resume_stopped_resumed_lwps, > which is the one location where I wasn't able to convince myself that the= assert should hold. > > I was running your test case executable (osm) as an unprivileged user,=20 > so neither the syslog calls nor the sudo were working. (Sudo could=20 > perhaps work, but it wanted to prompt for a password and stdin and=20 > stdout were closed.) I've since modified it so that sudo isn't used=20 > and I'm using 'fprintf(stderr, ...)' instead of syslog - which is how=20 > I discovered that sudo wasn't working. I've tried next'ing quite a=20 > lot, but so far I haven't reproduced the bug. (Hopefully, the sudo=20 > isn't required to reproduce the problem.) > > If you manage to reproduce the bug on a Raspberry Pi 4 (and tell me how t= o do it), that'd be great! > > So, what I'm doing, using three separate terminals, in an attempt to repr= oduce the bug is: > > 1) Run osm in terminal 1. (I didn't want to mess with systemd.) Once I = start running it, I see a bunch of messages from the dd command. > > 2) In terminal 2, I run: > > /path/to/gdbserver --debug --debug-format=3Dall --remote-debug=20 > --event-loop-debug --once --attach :1234 $(pgrep osm) > > 3) In terminal 3, I run: > > /path/to/gdb osm -x ./gdbx2 > > (I've changed the target remote command in gdbx2 to refer to=20 > localhost.) > > I'm also attaching my hacked lupdated.c. If you see anything wrong with = what I'm trying, please let me know. > > Kevin > > On Mon, 24 Jul 2023 13:36:24 +0000 > "Yan, Zhiyong" wrote: > > > Hi Kevin, > > The callstack of assert is attached. > > Please see attached gdbx2 which add more 'n' commands, on arm platf= orm, keep execute 'n' command, this test case can trigger assert error. > > > > Today, I didn't finish setting up test environments on RaspBerry Pi= 4. Before I produced this issue on Xilinx arm platform. > > > > Best Regards. > > Zhiyong > > > > -----Original Message----- > > From: Kevin Buettner > > Sent: Saturday, July 22, 2023 4:50 AM > > To: Yan, Zhiyong > > Cc: gdb-patches@sourceware.org; luis.machado@arm.com; tom@tromey.com > > Subject: Re: [PATCH] gdbserver: Install single-step breakpoint for a=20 > > pending thread whose last_resume_kind is resume_step > > > > 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. > > > > 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=3Dnative-gdbserver=20 > > both with and without your patch. Some of these tests are racy, but=20 > > my conclusion from just looking at the PASSes and FAILs (after many=20 > > test > > runs) is that there are no regressions. > > > > But then I remembered to enable core dumps on the Pi and after=20 > > running=20 > > gdb.threads/pending-fork-event-detach/pending-fork-event-detach-main > > -v fork by itself, I saw that it left a core file... > > > > $ make check RUNTESTFLAGS=3D"--target_board=3Dnative-gdbserver" > > TESTS=3Dgdb.threads/pending-fork-event-detach.exp > > ... > > =3D=3D=3D gdb Summary =3D=3D=3D > > > > # 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-gdbser= ver/bld/../../worktree-gdbserver/gdb/testsuite/gdb.threads/pending-fork-eve= nt-detach.c:29 > > 29 x++; > > [Current thread is 1 (Thread 0xf7e10440 (LWP 4835))] > > (gdb) x/i $pc > > =3D> 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 longe= r under GDB control, it dies with a SIGTRAP. > > > > This core file is not created when I run the test using a gdbserver wit= hout 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 =3D 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 wa= s 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=20 > > locations; in each case it was in a block in which the condition > > lwp->bp_reinsert !=3D 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 oc= curs so that I can see which call to maybe_hw_step is responsible for trigg= ering the failing assert. > > > > Kevin > >