From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2063.outbound.protection.outlook.com [40.107.22.63]) by sourceware.org (Postfix) with ESMTPS id C2184385842B for ; Mon, 7 Mar 2022 19:39:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C2184385842B ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BlK8ZhFXh3PM4bMoPgRe9japRQYionK0CqJdBlfOPTbXVSJQeY3f5/cM0EjSz1fU1TYbwy8jFg2f1JsSq5PQ2URDI39NckLTYAPjKNe18UwXgo3DBOVK8vEKO8yuxpNzfHMp1JOZJzVg77ghdHvUkfeoL1/TnOd1sn20z1eGQWST2/Rxh+UAj2/e+XDyX9odgadcjb8pz8LCgspRX6OHIVNcz9++qQlHO16J7Dnj+cz9qY3HFqEzCTu3Ryd7vD/8gP8fH3XREsGVuXUovpJlSZKt6+VINZmI8wMRolw0Q6WOkYMgxxnTca9rNg4NCMtAuFojHwpqr20eXji+RnIBmA== 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=33JfHSvKfmGreNdOBr8paXbixTcBWZpUS2eYbpk2ECY=; b=e0qJTeY2R6FN2ZCiyyNS77/lEsb7xkRaDzS0Gzh0ldePIXkRzYHnvXPT0zGHVxOg+xqfQW+tM4H9FO+vQWITziQ6n1PT5LfJPr5q12QPlJc03bY8fsrSRIa0mEtnOzIf+g4NtumfIwXUtTpcGaS0s4wZ3c7BbuKtKigCTpUIS4d4DW5dJKtSRvN1V5HaPrIiTEWwhzF8uDHP/KqhZfbDY5XGXUU83yUbkCdfvE784EoN0UgKLT+8dFgUFBF5Zd34ChcTwTqwIFAff3elxj2rq7wvxYCk+W9O6X6eZ8wY+e78uzUntSwaKOLvsHh1qJjOMSJo/eRQx7OE4VhdLf79Pw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none Received: from VI1PR0402MB2863.eurprd04.prod.outlook.com (2603:10a6:800:af::18) by VI1PR04MB5359.eurprd04.prod.outlook.com (2603:10a6:803:d1::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.14; Mon, 7 Mar 2022 19:39:41 +0000 Received: from VI1PR0402MB2863.eurprd04.prod.outlook.com ([fe80::7573:6988:63b7:b709]) by VI1PR0402MB2863.eurprd04.prod.outlook.com ([fe80::7573:6988:63b7:b709%9]) with mapi id 15.20.5038.027; Mon, 7 Mar 2022 19:39:41 +0000 From: Adrian Oltean To: "gdb@sourceware.org" Subject: Semihosting in GDB 11.1 | Proposed patch for interrupting in sync mode Thread-Topic: Semihosting in GDB 11.1 | Proposed patch for interrupting in sync mode Thread-Index: AdgyWiyLLC/HMj8SQmeHPEL+nhAQZQ== Date: Mon, 7 Mar 2022 19:39:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a487251-38df-4113-1632-08da0072393b x-ms-traffictypediagnostic: VI1PR04MB5359:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c6BPlp4YzNbJTLDhD7ompdYgkFerAAwV5vGckmvtJkLXNkk9jc+J5ZT4IfHe7iY+rXjiSpxKDi6h7ORjnDdr/sTgovhcwg0sYWU4IbaA4ddvFJ9ej9vnsH4XtoZK3D/w+GuCb3vVgjALUpcnT3vVgqs6KFH5F6rrW4BSbdq4m9ZJl8SQnyx2jhkJenVjn472+qTvtAaDY10Z8I0FsereSqTjrG/RDFwddHAByRkzEVSFglSgmF9Gclr319fYRTaq79IkFcDwxM4KFn9AsElOKi3j4JfplYgg9TkvsStel8/3TafD1kZ9y/qHlzzOc5Te+JUqV23N11HZ+Kaj6MovYjY2UPukcdKhAoHp3AeVDhfuVwGur5RvFpBS+lr/Dm1U3WvOhLhXFLIQ8tHohUGv8eL9AOLND/Xrkrbs37wZ8yqPU+hME7m03YwQrs0gllEvdU9AX2QYpLk5AlZHeH9LbqNyCA+YYayd+LDZfzL105toBU1qH6ojAX3eaMJ/i/fFOtbpOvOXT8QfmfoCwyUsJAnpPLfeW9IcvlcQeQjUPZQdyDXVSdCMld0oOSZ4X2odlIgUXA3V4UXs1/ZgAnuwENZjnL2h/5V68CDj4PfD9CY66AxVz+wCchiJPEf9qTsMG+gcHcG6MeFRsPOiLG3bgcw8V2nKjGa5Mmgo7hwwtx+B6PX2Rkh7K3CXUJ8nsH++dJh2QgyfbmB4/VYnQO91igpZrVIohNd8CmPll3yn2BM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0402MB2863.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(9686003)(55016003)(55236004)(6506007)(7696005)(2906002)(33656002)(76116006)(66946007)(66476007)(66446008)(66556008)(64756008)(8676002)(508600001)(71200400001)(122000001)(316002)(38100700002)(86362001)(38070700005)(6916009)(52536014)(83380400001)(186003)(44832011)(5660300002)(8936002)(26005)(2004002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?cFt2qcpBRENGKaHA9piR4OapgfZfzojSx+2cF5+04+eabKzgvhUcZlyvsmTG?= =?us-ascii?Q?ikvD4mpfKlsj80r3RQzze6wr9KCO/9ywnPjNodtLp30F2lYEA0Ve/oJ3BJDZ?= =?us-ascii?Q?XQLzVUJZnvCeWtgsY8ImEdtIOMBBW9ZHH26w50VUQWKjNqzmaSjDwjPG22dL?= =?us-ascii?Q?ia6TQZqbLRLXB9nKFVomQLBiTZ6da5ud0KQ4WqxNf2Pk7HhWeZgWqYGaq72X?= =?us-ascii?Q?+R+JAE2GdyARNX91OfQBGtVLlhKshpvWFjHGbQIV5sB3b6NdeAIy0cS085EO?= =?us-ascii?Q?0+RqyQoBrn1TXjBehLZ/yC7TrsP0SKIqQfF9Ek0YxU/i+oPgYBdDlGOVsrOk?= =?us-ascii?Q?cLg9BkBDN9CTLoUK+Iedd7Grwnw1+dsWZCsiXiuq8eUjdO+hl/0tTsGofgSw?= =?us-ascii?Q?0XWjj3goMEwBXbzS3FpDlUtCDhjVMCZZRbTb8R2iN4opt8hCifL0Otoq3Ta4?= =?us-ascii?Q?y54nc+f4yoM3X6ExQ++KXiGSAiv+Ru5fcoD3ugp1qAwuRyHllkTSlQwQw4ER?= =?us-ascii?Q?+ms1TOAJqjGzFoOFdT1orzlkC8yeA2WRx6iIH7Sj0CfxM3M6OB+in+GF5Mpk?= =?us-ascii?Q?ZZjz54Lbk37L0PMck2yYcq0AoRgUVaUGJgggX13cmFtxqEE/cBhmzqpF2uQx?= =?us-ascii?Q?/aCgTaEHuZaTW8ixUwwS3MrFLh5b6TjaGZj5mkCRvoINvOuKRSbIpZ92f2Tt?= =?us-ascii?Q?kfuULNtv/jNgEZB7RTjzxJPF8+FjSNlrJE6cV9080n2sY7vzAfIupKi0l2VZ?= =?us-ascii?Q?Mkye1+z6oGuLKiJsCKDW9dXAovpPuwopUQaXIzL4zvWUjue/6QGDDux4YFQN?= =?us-ascii?Q?bQPB/rVm9tDPnfRd47FpvCUUkui38sbY6Z5cb/aSOZTFpbToJuaLIVMk4eSr?= =?us-ascii?Q?Mzk9EouAHDga+mo9HRgc30oHgS0YOOS5pa6P8zLUBjZUvGFjCdOpVqMDGIl5?= =?us-ascii?Q?aN0EK2O2lc3XJm1UONLzt6WSicC4kCbluEm5Xpt2n8jtFO+578WfZup0m1JV?= =?us-ascii?Q?C/VQjwywMO238VNoquSh9Pb1Qz+RIftcSvjJKsf3MM5/zG7jjE1tmU6AywRE?= =?us-ascii?Q?+Ov8iLtDUVhhl1e6UdRdzSUAEn0shgpwMhRpmocniG79Fvq+cImrUJVNicCg?= =?us-ascii?Q?VPtibVrSWsIuNnIM+/sG+WC8L8MChg04u/zpNj+33xnj3hlnoefy+D4GiaM/?= =?us-ascii?Q?X93C1Gk0GmqVOHjCvtezwKdAPHDIhtwl6B4XvavqLBImKxjRhBmPsuPjpj1B?= =?us-ascii?Q?ufEiAgllOC/30cJf3Efux/v3GsOT4vUemeCj7NBQQ5w0y1TVAevs6fpIK0e8?= =?us-ascii?Q?jZzSsbzrDmOQJ9c9yZ6QWi/HMNAotqns/ZbE9Rt1d8P3pTQ4bBzJnvdkhkAw?= =?us-ascii?Q?DzQBeUsq6onwu7Ndf6tQLDXijjYG4srezF1i8d0jDfRl1O4owAUkT3HHAMi8?= =?us-ascii?Q?Li+b2byhAxDD6FUMizQnStn3a6QmfailtwbtautWtxJm3qjuewRYcBShTIBI?= =?us-ascii?Q?LiC1Pnxy2kLpdRwMRSZkGZaiPx+zlEmXEstIuMYmDcPgRNrerhx2YDvuZElV?= =?us-ascii?Q?FMzC27OHHfx6kw3S0rA9dNzIMqbAztNbX/bwIkSmvFR5bw9qraAegA3mcd+L?= =?us-ascii?Q?bIt6nbOCIdnQXER5ObqJJeI=3D?= MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR0402MB2863.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a487251-38df-4113-1632-08da0072393b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2022 19:39:41.0135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yrwKtanaWJ3DDu48U0bGcre/BR3uABh//oW3L/Qt3CDSTBO9ydr1wDLfldQ3GKoDg0nfo/z8+Od6ADRB3W49Ww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5359 X-Spam-Status: No, score=-13.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 19:39:47 -0000 Hi everyone, I'm currently in the process of upgrading to GDB 11.1 (from GDB 7.11.1) in a product that's based on Eclipse CDT, GDB client and on a proprietary GDB = server implementation. I'd appreciate some feedback/comments with regards to the following two topics described below: 1. I need to run GDB client in all-stop mode with target-async set to off. This seems to be a must in order to make some python scripts (containing gdb.post_event('continue')) interact correctly with Eclipse CDT and with some automation I have around the python scripts. Long story short, I patch= ed GDB client with the changes below in order to be able to interrupt the targ= et after posting a 'continue' event via python API. On a first round of testin= g, everything looks fine but I'd like to know if there's any chance I'll break any use case with these changes. --- gdb/target.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gdb/target.c b/gdb/target.c index 7875289819..d2516705ca 100644 --- a/gdb/target.c +++ b/gdb/target.c @@ -1,6 +1,6 @@ /* Select target systems and architectures at runtime for GDB. - Copyright (C) 1990-2021 Free Software Foundation, Inc. + Copyright (C) 1990-2022 Free Software Foundation, Inc. Contributed by Cygnus Support. @@ -937,7 +937,7 @@ target_terminal::inferior (void) /* A background resume (``run&'') should leave GDB in control of the terminal. */ - if (ui->prompt_state !=3D PROMPT_BLOCKED) + if (target_is_async_p () && ui->prompt_state !=3D PROMPT_BLOCKED) return; /* Since we always run the inferior in the main console (unless "set @@ -974,7 +974,7 @@ target_terminal::restore_inferior (void) struct ui *ui =3D current_ui; /* See target_terminal::inferior(). */ - if (ui->prompt_state !=3D PROMPT_BLOCKED || ui !=3D main_ui) + if (target_is_async_p () && (ui->prompt_state !=3D PROMPT_BLOCKED || ui= !=3D main_ui)) return; /* Restore the terminal settings of inferiors that were in the -- 2. File I/O (semihosting) when a multicore (ARMv8) target is involved seems to exhibit an issue. My multicore debugging model assumes that each core is= a separate thread. If I have 'printf' calls executed on separate cores, I not= iced that the messages are duplicated on secondary cores (other than core 0). Th= e remote log snippet that highlights the root cause is pasted below. Long sto= ry short, the 'H' packet that is sent to the server and instructs it to use thread 0 for some further operations, actually causes troubles because brea= kpoint handling and run control gets broken afterwards. Note that the 'Fwrite' is = the result of a 'printf' on a secondary core, thus instructing the server to us= e thread 0 breaks lots of things inside the GDB server. The 'H' packet seems = to be sent as a result of the 'continue' action and it translates into a call = to 'switch_to_no_thread'. If I ignore the 'H' packet, semihosting breakpoints = and run control are correctly handled, so the second 'Fwrite' RSP sequence would no= t exist (this is the expected behavior). Is the described behavior a known is= sue inside GDB? Or do I have to change something in the server to correct the described behavior? [remote] Sending packet: $vCont;c#a8 [remote] Received Ack [remote] wait: enter [remote] Packet received: Fwrite,1,80026300,12 [remote] Sending packet: $Hg0#df [remote] Received Ack [remote] Packet received: OK [remote] Sending packet: $m80026300,12#8f [remote] Received Ack [remote] Packet received: 48656c6c6f2066726f6d20436f726523370a [remote] Sending packet: $F12#a9 [remote] Received Ack [remote] Packet received: Fwrite,1,80026300,12 [remote] Sending packet: $m80026300,12#8f [remote] Received Ack [remote] Packet received: 48656c6c6f2066726f6d20436f726523370a [remote] Sending packet: $F12#a9 [remote] Received Ack [remote] Packet received: T05thread:p1.8;core:7; [remote] wait: exit Thank you for any comments, Adrian