From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) by sourceware.org (Postfix) with ESMTPS id E031B3858D35 for ; Mon, 20 Nov 2023 20:25:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E031B3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E031B3858D35 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=198.175.65.10 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1700511906; cv=fail; b=mrDqMZd/ojDoX3EEgAOX+oDVHA8dl9ctH3f/NNSiY3FaAPmVozeUsAOQ8GeWKSxzHI24rC3wsmDbYoh03nYVxC+/qXgd8UW6YUxRUQdqHCGs8e199/D1BC38vGR5N954qbr0M8ojYzMpF2E/9iunVxLNUVoJIvaVLJ/Z6uW7azg= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1700511906; c=relaxed/simple; bh=6kamXBGrXCauO4cGClD7ST6InbS16aml0lnC+81pKKQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=IcAyqHIpDGfiYml/A0ti72U0Ar1+Wqk7Uu5vZjoWVcdNhuENT98q2gSr95ctGlpq09+2KvvZ20VY71+2y6ytuCn77+omV72QzzpH7AHf7YOJVSQG6khgeDS0i6rHfZzRVtamBjVi5oxrKu5IwvGHRj5sX7plsAD8UytNP733KMU= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1700511904; x=1732047904; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=6kamXBGrXCauO4cGClD7ST6InbS16aml0lnC+81pKKQ=; b=gMLPHh4x1klqHyPLYfeXsaxAMv6oGTO42dExP89UySXbheOnUkYudC3t SH/vEy5cKjK7f6otiNcp4AnpMObgiQ7MZyfUEScF1LfLJYx3CWuKmHR9n jqzrq7MIhKoKmVr2XeXKir5uObCy8/iCMcOqBzoHHU4IygV2ZULFa/9Di M7O1JSDkw7ZQ8MzR/XrMCWxEi5ewc+g7lr/vLNL2EE5vmgqaBIjcQnIqr dcme7iQizSr9bvzg25IeZ6hGeaAQ5T1kDdvbzb3TFnlQRBbUTmrR12IpY 0SR/SZXxHB1s3hUKjkIU5X34SQoTlnYTPGH2qdGxItd78/lr3woSiRMuF w==; X-IronPort-AV: E=McAfee;i="6600,9927,10900"; a="4892532" X-IronPort-AV: E=Sophos;i="6.04,214,1695711600"; d="scan'208";a="4892532" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2023 12:25:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10900"; a="759883388" X-IronPort-AV: E=Sophos;i="6.04,214,1695711600"; d="scan'208";a="759883388" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by orsmga007.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 20 Nov 2023 12:25:02 -0800 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Mon, 20 Nov 2023 12:25:00 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Mon, 20 Nov 2023 12:25:00 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34 via Frontend Transport; Mon, 20 Nov 2023 12:25:00 -0800 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.169) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.34; Mon, 20 Nov 2023 12:24:59 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EMoHrVhKGe0Q3qa0YjMKtXE/yFOF/RGaVi/P1NremOz+1jX94JX73/ksOTOYBa+2qqZxOxih0iK/Txxh07Fv9wbxTpO5bpJ3jjLYPNBeb4AQqJcncmyo+GY46IOLaklqEq2tVanjgbjBBrIV8tgub8AtozboZQEFr5itLf1Kj9jYaJP5ChVnYFeaPZrGDr1A2LweBWuNd/v85O6hqO8mxEzCtifwIDQQm7w4naxxV2Asyyl8NAZBaVKgLP3uh2ZwWHukgXnhOm0BOXaLAaQjpv3pvGzOBALE4MlritPvy/gacN9QLUAfTjBN3Y5BtENIcdbkCbBj936w79lET5jQOQ== 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=d5FUb3zPD8xUFiJXtrlxVfq6OswOGav0nzIPUGPRquA=; b=DG469OCAeiRgDkVHHLFQnLvrfXneIgJV3rUBcX5whuPbM/HxCUfKwrsz3l74IY3wMiQ4/jY58K5Asir2yfrYPZr+qztwHxXvmcup2rRQ8MBBvADY9Oq0oAshrK/oDJrcXquClVqvjw6iutkfxTVH5gCAS+6h5wazbDmpywMYw0hPHFvbMCgnuIYvnA+aohmXOps3joxr5BSay/I1KP6bRKF3XM3FRL/eViV/Euqkdw/Pyx87MUjoqMIMb2PcN9OGha83LCA3JQ4c00mKnGIgw1FKfST3/mwPAdGYZ5bXhQeyVUPv1AufegNONC2NB1F8SevDfMGF05JLIVQW2bmpNQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from DM4PR11MB7303.namprd11.prod.outlook.com (2603:10b6:8:108::21) by PH7PR11MB6676.namprd11.prod.outlook.com (2603:10b6:510:1ae::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.27; Mon, 20 Nov 2023 20:24:57 +0000 Received: from DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::9597:5d8e:99f8:b993]) by DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::9597:5d8e:99f8:b993%5]) with mapi id 15.20.7002.025; Mon, 20 Nov 2023 20:24:57 +0000 From: "Aktemur, Tankut Baris" To: Andrew Burgess , "gdb-patches@sourceware.org" CC: "blarsen@redhat.com" , "tom@tromey.com" Subject: RE: [PATCH v4] gdb, python: selectively omit enabling stdin in gdb.execute Thread-Topic: [PATCH v4] gdb, python: selectively omit enabling stdin in gdb.execute Thread-Index: AQHaFuq4EDPw6la5q06vTLKP7AXiBrB803CAgAbaQkA= Date: Mon, 20 Nov 2023 20:24:57 +0000 Message-ID: References: <20230331081114.1319992-1-tankut.baris.aktemur@intel.com> <877cmiq6fu.fsf@redhat.com> In-Reply-To: <877cmiq6fu.fsf@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR11MB7303:EE_|PH7PR11MB6676:EE_ x-ms-office365-filtering-correlation-id: 53847b15-cd04-4816-64bc-08dbea06c3a9 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: J+UbMD1ggC3D4wmZlvs4t6iCwndFFjNCI4UoIYBWLD5ffid5rNkvYOgQeu2tXtVQRRgHsKSLI2MdaKBTMPDXCCuVjjDn7T0n7AuriZJGqlPhP6bNVFQSFeAwTp0OjQT8rbjLK+GCCPhz0zteUevR6WUxlfTQRIQv7uF1ckBxsSXt1EjSvtjrYR5a9EjUwhawXNH89wcZ0luKbrAXZj7S4xx69ieS9lzMcNr9u1Z20oDUT7Z+YyGRlwnkCRMZtjtWcK/id2jObfJndTdI3qiwApH8qoYBW9XxC222tjHe22d1ZD8PpM5RIIgpvXpzE6ZdEVnthJuVCoUxU728IqLtnEKrz79jSYZPhMLbWteajYe/aRB+GB1q7/nz/6UXi756Dmk0uGGOzQIYYcC8WjT+fI52nYCh5p+s9GIh51dA4gJDCsK0oMge4tvYZ5ny/55BM81exyiWZ7ZovtUU6lGzwMMwd0Mf4lupIageWhHxD57s5JCDW3BZNv9u6pMFMHrtniUoQPUwoD99SGT0MrRIqW8F/n7j3EJyQ2v4m4mTnbBNBe2tI2wYAzHWzOzDYcrHIWPlryGGYBpU+rWsMeM0nMqfaB/OpU0PnquJkmicmJU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR11MB7303.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366004)(376002)(396003)(39860400002)(136003)(346002)(230922051799003)(1800799012)(451199024)(64100799003)(186009)(84970400001)(2906002)(55016003)(8936002)(52536014)(41300700001)(4326008)(8676002)(5660300002)(316002)(66946007)(64756008)(66556008)(66476007)(66446008)(76116006)(110136005)(54906003)(86362001)(966005)(478600001)(26005)(38070700009)(71200400001)(9686003)(53546011)(7696005)(6506007)(122000001)(83380400001)(33656002)(38100700002)(82960400001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?RkMogwPMDdKWT472/cK4chz7QsiU4i+oNACk2LRAzt2P8YVQ9SZug9O85gso?= =?us-ascii?Q?V1s/0M9UnWD6TX5o6qRV6VLlj4lOnO/Qutab81wZPa/K/ixr0gTUs5+jKu94?= =?us-ascii?Q?rzfVqal5z4PmgKyDDsMS2uteC300nzcghar5NW13yKj05PZsIKQPHITlRj/a?= =?us-ascii?Q?p8QariH5fKcjVjyY/mdCbPhBPTtYSGx6lhBMZJdznYOroJ3sHwj7aSFdKXbO?= =?us-ascii?Q?wevnFjExFfyQng/7AQeX2dalU/JHN1iiUosr+AAP02E8qiZ56ptG6ScoTIcD?= =?us-ascii?Q?t9P/t53Ct03a++KEv2MFGRSiHWJR0j/apZwSNdhK0LbMeSTDCcdtUOt/PfEK?= =?us-ascii?Q?DZ0bOZgwys/prXb1nTPQQyUilbLSZtNUy39RkNPDmFzy1ujBd7n801Dgdlyn?= =?us-ascii?Q?Y7/8NhzRVcNpQ4ARy5imqkR/0rMq8ZfNKjIarJLke9U+xm0d8S5txlCrJAaJ?= =?us-ascii?Q?+1/yjKghBOEqPQrAU6CaYgic+8zLBgW5ersNi4rmze7F4/kuTM/FZMOXyArH?= =?us-ascii?Q?vmpxD7o4milX8ow9rFANqLGzKsHTAsr2KH3tQoK3RouRALoHTCd+AnmlMjZf?= =?us-ascii?Q?aJHUHLS3KN0iFGbOUSPNzjypClML/m/zHenVE27sJuxQCvlnl9cRDNCz+eMn?= =?us-ascii?Q?nQUG1GGEyBfP6TCajT2EeDgFBpcvw53ZwoLK/VwC5OGorOcSPlHSLZg7dOOj?= =?us-ascii?Q?n3CvAY8c/lEHu63cDiI5x79S8H3xRpfsvqYaLPKnMEpV0Sm5zg7uxDOyyCOZ?= =?us-ascii?Q?dq6qFWLWYMCypVF8RAKyWdzsql4Dj3no3Co2uxudEfB3EiLjeuIfLRGcFfJs?= =?us-ascii?Q?A2qVeW/aMIO6YJD0ZaLqbSwflH8vftHeh4LFWJVQUt/gd387EUsRxEuQHw+j?= =?us-ascii?Q?xpd1sVOm+JPe+axCyeBYP3UIaLKXBSRAUMLUb0sc8aYHN7UaVYQ+WZfTas0D?= =?us-ascii?Q?a9GMuzTTrn8tPQm5UuHbrNFDJWNe2pEyNp1X2aGOHU4f06Zb/9oVP90j5rtP?= =?us-ascii?Q?yqDTQ7CVSmUAZJc3CPEFOVjWzwXQDvGzzo8495kBezz8rnbJLhatx3JVbvs+?= =?us-ascii?Q?uozmqMU4cQpyCIsModAHNy8yGJywjLo9lLLnlsMxacwP+bC5R/klKvqTYpKh?= =?us-ascii?Q?Hhd/OyUEWEdLTYthZZI3av/+AOgVoukLZA5oaqxX5L43aXmYErnSjXhinHw+?= =?us-ascii?Q?Hq7qgr0NoPsj+Q2vmytSt3zXQsgbA+BfHVHfVhoKXfy4d8BvpVKNmE4jGl7T?= =?us-ascii?Q?5GPnu7OMMR6cs3w7sYnnENjXe3CI1s8CIQxEqb8gB1iwBxvCXkdqk/RqLS+q?= =?us-ascii?Q?4MPM1uD85JvmZ1wrh179FPrTv5p8zwZheFp8YZpoxcum9SaIP+7CIYS7cfSX?= =?us-ascii?Q?lb96l8PrRXsjE/ZAeHeDOWAyCAV44mCaLrXw1hPLmrLc+StU9hTBAdOAPNbU?= =?us-ascii?Q?3TeuG8lpJKZFyzSZJZXv6fiY5T+1ClmfqCG6/GdVJw95nhPYebYYdtpDKkNq?= =?us-ascii?Q?CafCv2+RmEIoANG+/GEdSkNdypnxNq36EAgv1fyEiTIXn4REEHGmTKDcXnu3?= =?us-ascii?Q?J/NneJI6afKx0W91/cPvDoFAdonYTWGo38V/zeHylPoZ8dla1jIQBdkBm8bi?= =?us-ascii?Q?Ww=3D=3D?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB7303.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53847b15-cd04-4816-64bc-08dbea06c3a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2023 20:24:57.5806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2YdcjjNmYE3swtYVOOXMVIHcf8nJEhYXJ/Y5Tmbr96BqmuvLY1lZTq8yGqcGX5DdINa7UUwlmkKSOlYFOC8ByC0SeXyF5FmT3VbxP/VZ0aU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6676 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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 List-Id: On Thursday, November 16, 2023 12:33 PM, Andrew Burgess wrote: > Tankut Baris Aktemur writes: > = > Hi Baris, > = > I took a look through this patch. I have a few thoughts. > = > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Hi, > > > > The previous revision (v3) of this patch can be found at > > > > https://sourceware.org/pipermail/gdb-patches/2023-March/198508.html > > > > Changes in this version: > > > > * Rebased on the current master. > > * Added a new test scenario in gdb.python/py-cmd-prompt.exp. > > * The new scenario made me add a new boolean field to `struct ui` in ui= .h. > > > > Regards, > > Baris > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > From the Python API, we can execute GDB commands via gdb.execute. If > > the command gives an exception, however, we need to recover the GDB > > prompt and enable stdin, because the exception does not reach > > top-level GDB or normal_stop. This was done in commit > > > > commit 1ba1ac88011703abcd0271e4f5d00927dc69a09a > > Author: Andrew Burgess > > Date: Tue Nov 19 11:17:20 2019 +0000 > > > > gdb: Enable stdin on exception in execute_gdb_command > > > > However, we face a glitch if the Python side executes the command in a > > context where GDB had already disabled stdin, because it was running a > > synchronous execution command such as "continue" or "run". As an > > example, suppose we have the following objfile event listener, > > specified in a file named file.py: > > > > ~~~ > > import gdb > > > > class MyListener: > > def __init__(self): > > gdb.events.new_objfile.connect(self.handle_new_objfile_event) > > self.processed_objfile =3D False > > > > def handle_new_objfile_event(self, event): > > if self.processed_objfile: > > return > > > > print("loading " + event.new_objfile.filename) > > self.processed_objfile =3D True > > gdb.execute("print a") > > > > the_listener =3D MyListener() > > ~~~ > > > > The executed command "print a", gives an error because "a" is not > > defined. We use the listener as follows: > > > > $ gdb -q -ex "source file.py" -ex "run" --args a.out > > Reading symbols from /tmp/a.out... > > Starting program: /tmp/a.out > > loading /lib64/ld-linux-x86-64.so.2 > > Python Exception : No symbol "a" in current contex= t. > > (gdb) [Inferior 1 (process 3980401) exited normally] > > > > Note how the GDB prompt comes inbetween the exception message and the > > inferior's exit message. We have this obscure behavior, because GDB > > continues to execute its flow after emitting the Python event. In > > this case, GDB would enable stdin in the normal way. Hence, we do not > > need to explicitly enable stdin in execute_gdb_command when an > > exception occurs. > > > > A similar problem occurs also when the command completes without > > exception, but if it enables stdin upon completion. The "target > > remote" command is an example for such case. For more details of the > > scenario, see the test case added by this patch. > = > First, thanks for digging into this problem more since v3 and finding > the additional case that justifies the approach taken here. > = > However, I think that the commit message is showing the legacy of the > original problem. When I first read through this, my first thought was > still exactly what Tom suggested (I hadn't looked at v3 at this point); > that we should record if the prompt is blocked inside > execute_gdb_command instead of adding the new ui member variable. > = > You say "A similar problem occurs also ... " and yes, the outcome is the > same (early prompt), but really I think this is a totally different > problem which defines _why_ we need this (or something like this) as the > solution. > = > Also, why you say "For more details of the scenario, see the test case > added by this patch.", this isn't super helpful. Yes, the test gives an > _example_, and there is an explanation similar to the above .. but I'd > really like to see far more detail, e.g. a discussion of the call stack > including start_remote and normal_stop, and why this is a problem. > = > I suspect we can grep GDB for calls to normal_stop, and if we can > trigger any of these from Python as a result of an event, then this is > another broken case. For example, stepping into an inline frame calls > normal_stop, so I suspect that using 'step' from a Python event could > break -- not suggesting that more tests are needed, but maybe we should > mention that there are multiple ways this can break. Thanks for your comments, Andrew. You're right. I should've explained the reasoning better. I've updated the commit message in v5. I hope it's clearer now. = > > > > As a solution, we track whether the prompt was already blocked. If so, > > we leave enabling stdin to GDB. > > > > With this patch, we see > > > > $ gdb -q -ex "source file.py" -ex "run" --args a.out > > Reading symbols from /tmp/a.out... > > Starting program: /tmp/a.out > > loading /lib64/ld-linux-x86-64.so.2 > > Python Exception : No symbol "a" in current contex= t. > > [Inferior 1 (process 3984511) exited normally] > > (gdb) > > > > Regression-tested on X86_64 Linux using the default board file (i.e. u= nix). > > > > Co-Authored-By: Oguzhan Karakaya > > Reviewed-By: Guinevere Larsen > > --- > > gdb/event-top.c | 3 +- > > gdb/python/python.c | 29 ++++++++++ > > gdb/testsuite/gdb.python/py-cmd-exception.c | 22 ++++++++ > > gdb/testsuite/gdb.python/py-cmd-exception.exp | 43 +++++++++++++++ > > gdb/testsuite/gdb.python/py-cmd-exception.py | 33 +++++++++++ > > gdb/testsuite/gdb.python/py-cmd-prompt.c | 22 ++++++++ > > gdb/testsuite/gdb.python/py-cmd-prompt.exp | 55 +++++++++++++++++++ > > gdb/testsuite/gdb.python/py-cmd-prompt.py | 36 ++++++++++++ > > gdb/ui.h | 5 ++ > > 9 files changed, 247 insertions(+), 1 deletion(-) > > create mode 100644 gdb/testsuite/gdb.python/py-cmd-exception.c > > create mode 100644 gdb/testsuite/gdb.python/py-cmd-exception.exp > > create mode 100644 gdb/testsuite/gdb.python/py-cmd-exception.py > > create mode 100644 gdb/testsuite/gdb.python/py-cmd-prompt.c > > create mode 100644 gdb/testsuite/gdb.python/py-cmd-prompt.exp > > create mode 100644 gdb/testsuite/gdb.python/py-cmd-prompt.py > > > > diff --git a/gdb/event-top.c b/gdb/event-top.c > > index 9886ca46e7b..c24717eb2f0 100644 > > --- a/gdb/event-top.c > > +++ b/gdb/event-top.c > > @@ -508,7 +508,8 @@ async_enable_stdin (void) > > { > > struct ui *ui =3D current_ui; > > > > - if (ui->prompt_state =3D=3D PROMPT_BLOCKED) > > + if (ui->prompt_state =3D=3D PROMPT_BLOCKED > > + && !ui->keep_prompt_blocked) > > { > > target_terminal::ours (); > > ui->register_file_handler (); > > diff --git a/gdb/python/python.c b/gdb/python/python.c > > index d569fb5a3e4..eef0017e407 100644 > > --- a/gdb/python/python.c > > +++ b/gdb/python/python.c > > @@ -658,6 +658,35 @@ execute_gdb_command (PyObject *self, PyObject *arg= s, PyObject > *kw) > > > > scoped_restore preventer =3D prevent_dont_repeat (); > > > > + /* If the executed command raises an exception, we may have to > > + enable stdin and recover the GDB prompt. > > + > > + Stdin should not be re-enabled if it is already blocked because, > > + for example, we are running a command in the context of a > > + synchronous execution command ("run", "continue", etc.). Like > > + this: > > + > > + User runs "continue" > > + --> command blocks the prompt > > + --> Python API is invoked, e.g. via events > > + --> gdb.execute(C) invoked inside Python > > + --> command C raises an exception > > + > > + In this case case, GDB would go back to the top "continue" command > > + and move on with its normal course of execution. That is, it > > + would enable stdin in the way it normally does. > > + > > + Similarly, if the command we are about to execute enables the > > + stdin while we are still in the context of a synchronous > > + execution command, we would be displaying the prompt too early, > > + before the surrounding command completes. > = > As with the commit message, this comment seems to focus on the wrong > case. We should stress the non-local case more, as that justifies > _this_ solution over a solution that is handled entirely within this > function. In v5, I changed the order of the examples and gave more details. ... > > diff --git a/gdb/ui.h b/gdb/ui.h > > index ed75e041e5f..4303d11c58c 100644 > > --- a/gdb/ui.h > > +++ b/gdb/ui.h > > @@ -135,6 +135,11 @@ struct ui > > /* See enum prompt_state's description. */ > > enum prompt_state prompt_state =3D PROMPT_NEEDED; > > > > + /* Whether the prompt should be kept blocked. This is useful to not > > + recover the prompt too early in the context of nested command > > + execution. */ > > + bool keep_prompt_blocked =3D false; > = > In the comment: s/recover/unblock/ makes more sense I think. Fixed in v5. Regards -Baris Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva = Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928