From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-0064b401.pphosted.com (mx0a-0064b401.pphosted.com [205.220.166.238]) by sourceware.org (Postfix) with ESMTPS id 919373858C5F for ; Tue, 25 Jul 2023 07:06:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 919373858C5F 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 (m0250810.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36P4xcX0009929; Tue, 25 Jul 2023 00:05:57 -0700 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=4fxvn87av+xgtlYaU/rGRa09EzJiASkkO8v4UGhYmjY=; b= ZZRLY2pZoMnDJvh6vFCoSkEV9T6BZNn50gKvuQieyjx9U/IlNC90Y+vQhhboXyYl 9bAO/FjDokKxDM2OXLO6B2OhGnPIKK/UJKRi6NxhSyKCXl7Z+xbrNJ9HImnqz0QS t+Q4nHOgihJ+i86gBCHnmJbyGM5auAG8QoPV0651YiuFHw6iF5ivLuuKOuFx1H5i 2cnRkg71N038BXtkfXnwDJ8PAPWo0OjmyQ3GHNkDKD98YLto8o44dhxQoXp/1Mhw JYifW8LDV67dbu/wruIBr8t1a5YZVeMrsHNcVLzAItXZWVgRGuxURs257Au5wTVw R/6b6wAgdyrEgqpjDns/7g== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2172.outbound.protection.outlook.com [104.47.56.172]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 3s0ad024sr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jul 2023 00:05:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D8vDkh98y9lYHatrMHz9WMhymQJrmB7BkLIfRZz4v5cbFCVAn+baAZBtyMowMJHNFB9zY+yehYdyd3fJQT8hoVBVExsOi4aIxA4yX6b73NSIt4rnG8oOjrY4wXNCpkVNKRuj3lVutXTCf3zQ0PLQK+Je5qtq8n9IU3iW51S3MXi7zg/d7HGfAcjf40MA/C4SYA86zv9A1snfN50YwxkpKH9P7WD3LOuUUdiHytWdQAFCLZ9daOdfMQtRmfdMGAFjpngqPtj1xMiAkwFj0NzBv0EajfWUP+tqxOuwMA/V2PY7JTk1fqVphUoXPaqW2zFvIhwJIjjEjLwUwhphCIhiOQ== 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=4fxvn87av+xgtlYaU/rGRa09EzJiASkkO8v4UGhYmjY=; b=S7axsFgJDrfvy/AD+Iw3Nwc8E3Gnwi7fQPyA9vMVjC7iWtQ4e+YYuwjm7YzP1dKDSIODi7d/Edg/EqdooJidmv2zFmo5OGL4uyuFUisuFbqfY/hBTwDLfdI241gGLJ9S78qApYEQMh9tS2FRhSzhnDt3kdjpqWrrT99lf/nL2bCnSdT6ZB3DcDPeox/VKcCFrpP6pxEFxviXbIxGmuRdXyW8FXALF6lm1mKTYhKDnAuXR51k32rY7EYohdfOSQ1VC9SZZhlRiQ3rDynQGlCFQOl2vU0VQ8OybwmuS3S/wzSJeSXl3IjelwLCnoHBsb9bJD23VrQeu9Ntgj666x6VmQ== 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 MN0PR11MB5961.namprd11.prod.outlook.com (2603:10b6:208:370::9) 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 07:05:53 +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 07:05:52 +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/I7Y0wgADsxwCAAAm8QIAAJz2AgAACReCAAAZOAA== Date: Tue, 25 Jul 2023 07:05:52 +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: 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_|MN0PR11MB5961:EE_ x-ms-office365-filtering-correlation-id: 5cb02f67-5766-4a9d-95f7-08db8cdd957d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y/WleFXORuPhw4Kb7qBEpYrdkU9EUEAM3Oyfp0E4yN8QEmMbd8odOpVayWxrmQqYM5CX991w8b3VJsb7E1qDX87c+6CJNa9lZuE9IgNdIqUw6kxhAH57x9U+SUqaNvaLRp5ASpGwtJ9WasCWWVvLLD+PMpZIiUVnc2iZBgej880GnVEwxtA7MlPn6gixf9cxyn4jwgKFAKAVLxS8J50RcJ3Q6Vcl8VbOCie1rtb7dsusKZMq0xePowBgHgXXWUudVm8td54OvlipRneKW+yBPpx+cwWRTy3maHWWHyXSMucHllwBlD8N0Mm3kKzcOF0BA4ccwjIGp9nXCDp3BM9faq9pYtTk/gjaroX78f6YQEA8bnFR5pIy26ctR+tCfFOAlLNATpQolMmaVj1oLntCqytOM9YqrPCP5Y5x5z8oJA+bVqvsf8Jz7vEQRmA6KMqsWsRbLY8Thyxy3xmuUkcGMq3b051WVuHvri8qSxZUkDY6mjj5YChsaKGKZB9+Bj8DJBD2SPEQr3diwLPE1pjWKq3RasmR0+9tkIs2VkXxmHybX5VKC/02eqiHL/W3gBo8USmr6+kTqbgxDbwOE8fh9TfzJzZsX6scaodGMb/cRR8= 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)(376002)(39850400004)(346002)(396003)(366004)(451199021)(84970400001)(64756008)(66946007)(83380400001)(66446008)(66476007)(122000001)(41300700001)(52536014)(38100700002)(55016003)(33656002)(86362001)(38070700005)(8676002)(8936002)(5660300002)(9686003)(966005)(7696005)(478600001)(54906003)(71200400001)(66556008)(316002)(6916009)(4326008)(2906002)(30864003)(76116006)(2940100002)(186003)(53546011)(6506007)(26005);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?SPuOMrgVuUucsSrFXZMC6SXAq7Ji6OMBvCoXbu3Xa0+3nEQ5HvVJANy7hMUu?= =?us-ascii?Q?E9feLDZx3BKopG2HIOw2z8QK8aBeJISexncUT0vMMZ6Dj2mwf5kytsPdhht3?= =?us-ascii?Q?qRVXD3lJEiTtzErP6hIkWvekOs8zI7mvGMsqGTk1X01Oy4KEJNBAt5/6DpjQ?= =?us-ascii?Q?6T565xEQqYGn9p6AEzGB4aftYYlgUjcd8o3Ghk3bxFukyGTS8mWJwXzXJG80?= =?us-ascii?Q?pTgBSYN+vrNXjCkAtnGgGOaBhmB+kREs1M+nYfnpPpj6z8JYNyk0QSkoZnxa?= =?us-ascii?Q?ej1BfcsPMo+mh0e2lRTo8vB5CR3ZGUYFiMlMhkTfrfy/TeJsre+Rj+zNkaDF?= =?us-ascii?Q?bQBw+zMB4/pd9cdRvojm8oONCgqEFRMG9y8VIRWQ/2AkI9HVs9tOBCwSrkmu?= =?us-ascii?Q?U1PzB9xy5TAnFnGuJSvQrUU8pbqbTZ/esA1upAMLGycaOJ7fLcDzzhQvtU7b?= =?us-ascii?Q?JUBQFHFijmajmgv0JjsMzv3hLNQstQljm4KjmNzMTZsrYmMIZYStydIaxUwT?= =?us-ascii?Q?zXrvppCYHrmOjoFtzZDFO6kSoPUVfVyPwuGMrV1A4KLT/YAQqcpT5OYAkAm4?= =?us-ascii?Q?7k0Gf78Ys4egaZURvr3F4Jkcww6gtBx0szpmnLHMTBHC97m8X1cWWlpspP7e?= =?us-ascii?Q?AuZFAcCwFu7htS62dPtkezo93a0/SIWub0ly1Y5vmCUnuVItVJCjC8Lw8+wS?= =?us-ascii?Q?ccGZykopSupE8eMZED+wNUn6jESrAki6BauYie1Q3GT1lCh9FT29i18tFHhQ?= =?us-ascii?Q?L0FyYFSvCGHLn5FW2KYdHlK0UpSwqAKmy4k1N5zjI6P1TNyA2QPtErSzDYHs?= =?us-ascii?Q?UMEaeR98YwroeHTxlaHDRAxP4uwLhw648vjoJPT24Qgcd634TXltH8pWBbJX?= =?us-ascii?Q?Vxq3ik+V3WFWuHblZed4V1W34rPaWOmFFvd2X6b2oj+/AB7GaWsZfaLGlvpA?= =?us-ascii?Q?hhUgEKXvMOsTyQh3gN9/0dnVMogUvlyVB/Jgw8IJeWZ0AE9v8QllD0Zonw5Z?= =?us-ascii?Q?VFEZZOu7tihzs8C5OsKMh6/wMQcjnT0IT+Nd3qNjwi3j6NFsZAzHSdeGX0Nj?= =?us-ascii?Q?BWKEuq+gedIAY44Zkndh16Xz8lbyVbYidhmbkI8yM9mzkKC39KHO+3PF4VR5?= =?us-ascii?Q?rYxgihU0Qq70k6ZaCaRS/cd5X7TxMpJB69SfurP5JK8LEho9oAidFFLAx+Se?= =?us-ascii?Q?RiFDH5lj1CZDDPAdHBpaJovDTxZxwQbyvpWs7wp7rRsqXIN5WiMeZuD7mQxK?= =?us-ascii?Q?AW9ZoxVExuT69hf55dI9SjYdyAVmQdllr6OG8K/XZXSChMofWxrBQPtGw4HY?= =?us-ascii?Q?vs+WKYHK5PAyiWSS9+Mccrfdyy5nDgV+G3dcjekOr4w6UZHdnJRb/o9d+mFU?= =?us-ascii?Q?5VJFKCJzE7tXtiTyEVcTMOFxerIj811TX3H6NL2NIkAeF5+vhoaHpUbkdOMu?= =?us-ascii?Q?BM/Es9jxWW2hJfolhKfGFR3xmiW++me//+3e0byIzwRWmgQGfHhKtWOeljk4?= =?us-ascii?Q?/A4Bp+ZPP/CIoxEJcghafyKr6S3DkBPOxTyG81oJRpFqAuUkMOcpr3zZIXcS?= =?us-ascii?Q?iFXiSwDkP2A+tPdlEwwsnkHJLn/5P9eKmpXqN3ZG?= 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: 5cb02f67-5766-4a9d-95f7-08db8cdd957d X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2023 07:05:52.6232 (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: HFmLr7/iVU8VMbgBWMqF9DnxZShktZmsTOxyxy1wMgnZHY4G6ppiZggAYZH5cBBKyI4cZjmKW1VjMs3P9BmNsD5P2dr9eN8lF6Kl+cy9fi0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB5961 X-Proofpoint-ORIG-GUID: VvNnjQreRKZFsYSqi5jHtodj0asi9gEX X-Proofpoint-GUID: VvNnjQreRKZFsYSqi5jHtodj0asi9gEX 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 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 spamscore=0 impostorscore=0 mlxscore=0 bulkscore=0 phishscore=0 adultscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2306200000 definitions=main-2307250063 X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,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, Possibly the conclusion is Raspberry with aarch64 supports gdb 'hardwa= re single step', you need turn to another arm platform which doesn't suppor= ts gdb 'hardware single step' to produce this assert error. Best Regards. Zhiyong -----Original Message----- From: Yan, Zhiyong=20 Sent: Tuesday, July 25, 2023 2:51 PM 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 pendin= g thread whose last_resume_kind is resume_step 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/l= s.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 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 > 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 > maybe_hw_step() is being called from > 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 > 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 > >