From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by sourceware.org (Postfix) with ESMTPS id 6135D3858D33 for ; Tue, 10 Jan 2023 21:00:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6135D3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673384448; x=1704920448; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=V7kB+q9xkxFIhgg7B3Er9MHD6L4qWJvaC7KFmqDku8o=; b=Z5hR5o5nqNQlxte/Ys8Js+1e6YEIkDGLc7x7AHTi1JFcTgwb660d1f0/ hGQlVvJ1OcMu0MEubvzTjM3x5uWim6OVGYd4NHXaWQk+qewzdWGSqeGlb QMzEl2Bxl1u4YE5S4Zoa/1Lf9sERPV5cCWNb2xnwleALwLgFuTecUBw+y EFIpJ4Gb8dAc6DVFmp3ootHghk/rDlUM+v62b7bUm/zvIcsKOBBTbg6lS NJwRsJsDI4Be9sZ2kQVfQlYCB35WnhNPOBj0KlN1uPy3Bo0QvTCHAJuhZ 53NIeSxP877R0kJpdhCmT9PGCbV0fyaYXXCDS93KGvwDW3hVE8xz5NN8B Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="303627873" X-IronPort-AV: E=Sophos;i="5.96,315,1665471600"; d="scan'208";a="303627873" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2023 13:00:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="689542878" X-IronPort-AV: E=Sophos;i="5.96,315,1665471600"; d="scan'208";a="689542878" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga001.jf.intel.com with ESMTP; 10 Jan 2023 13:00:46 -0800 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Tue, 10 Jan 2023 13:00:46 -0800 Received: from orsmsx602.amr.corp.intel.com (10.22.229.15) by ORSMSX610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Tue, 10 Jan 2023 13:00:46 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Tue, 10 Jan 2023 13:00:46 -0800 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.175) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Tue, 10 Jan 2023 13:00:46 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PeJoV/TMd/kdY27oycbTR38m1JEVKtaaEJHG5O/B+ctAVaM4ivDBFCiTlNuE7o5sb3St7gSsEpeHbTZy1BKjMIN2za+g26ga36XRt/DDh6tHvRk+qvdO4ymT37gi9MaHCpZzbAqXhXfku54e7dpOGdp1LN1v5GilUygwftMpMzMdTmWmN1OXQqt6cVaXdSolMfhJsbrPTWUPsM0xLa6Jmd+7UOyVI6lbvh4oNq/hH3lsTJBy6d6N58ibf1hv6b9yDar6w4n+eneiFfjPrIfz6QxcXOxl6nutO+BfIiK63oBi+KZBQHLQtbrWoTXEUd+9SM2fp1VwTGcOqYcdzi3Epg== 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=jBzFP+jOMvEy0y9FSPu1P6wjm/t2v22oEk/4ireH+Qc=; b=PxVHhr2QzyoAmGOu0tgBGfdwoqq8OajJjUOasb6AmRBIsiUCxIR2pHtJxPqnu1F1fR1WoGNXy7s9F1tyBEqZ3wR9DkipMo8aFfx+5gR7my2dngsI8i9VQowglxxjuVxyzwXWmvGONrz+VLhcc6a8K0o4eF0+iUemCXVnwTqz/hIK41Mw5S8TFrVTjLg4UOeIkjsVYWL2+InwfcIoZNVyzSPQh9NkeSQsBJEW81llXQs4ndD7nAleQ99ExxYxyQMyY372+aoucxpie+3CyYjiqdsoGvtzEUJQTJnSXI7LMsPwQ1EljuV6jHcUaVdBCi5NiNp4UG3eNltPMj6OJRcFpw== 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 PH7PR11MB6380.namprd11.prod.outlook.com (2603:10b6:510:1f8::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.18; Tue, 10 Jan 2023 21:00:44 +0000 Received: from DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::d2a1:8dd2:854f:d5df]) by DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::d2a1:8dd2:854f:d5df%9]) with mapi id 15.20.5986.018; Tue, 10 Jan 2023 21:00:44 +0000 From: "Aktemur, Tankut Baris" To: "gdb-patches@sourceware.org" Subject: RE: [PATCH] gdb/infrun: reset thread control's step info in end_stepping_range Thread-Topic: [PATCH] gdb/infrun: reset thread control's step info in end_stepping_range Thread-Index: AQHY+e0yhid2YvAG6kuGZgxFBGgoQ66YeRHA Date: Tue, 10 Jan 2023 21:00:44 +0000 Message-ID: References: <20221116185624.3770349-1-tankut.baris.aktemur@intel.com> In-Reply-To: <20221116185624.3770349-1-tankut.baris.aktemur@intel.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_|PH7PR11MB6380:EE_ x-ms-office365-filtering-correlation-id: 3ee867dc-c3ba-481a-39b0-08daf34dbd5b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JxOf+1A6+ymVYAI0qzhOttXK6kiYRCZFUmUhhhIXu35+Nnjcw4JM1yfO8XQbmswNxWkQgk5l0LsT9+MRQSGZZ++6SllqBjlJEN64gwiBAOkEGRQykBIVtFclh0nyN87lZK3pmla+N76LoKrxpvwuK1AZE1F/5byFChskxvRJfCnQRvbwR6/4y6+kgE/DEq0bB6FxBz7lNHQnCmlC/pMkcAzS1AYw1KtFBHZXyxxwr8zPh2sgK7irJTfBDU6wBz9Iap/CraVZfAKGhuc6qHTigYetPtJoWUmEX0CfwR9fKx3e7+E9CLgXwfBHYAaBtnFCW2FpgAtCvHZi7t9Yx2RQ+Ubf7i0yW4Mi8ybgzDg1C5WmMrECpaJ+QWHfNp34UCdEORnJe28LM90qs4JP1sf5nwsMcq7BsILgrn4jO6LOIs4J93qAD1Qu+63VXxnGM6yWKBk5zN0R0twGNeBXBplnZwo0xHz3TRZFoUDTqBqx3QZkOVQzm7VhWHVIZk3Iafj6ezBURHm6SHv3ztn2mIzdGrB/y+DWTkNItxzWohJ23wYZQTUFoWbJrT49SXCG9FOh6dY67FV1VDG2uvAxDTrMTTJPdaiTcP8YvuzXdTZV0IA/mCrDaNI/j9resfMsUx1ow7GXxdOhXjwBXBEHh+iWtRhdMgMwf7bEM3srPxzxkTD6fhg6eDDskIH6+od/F3vvOOgkOwYIsNZh7owoF8TgZVzeKPJSjMIrn6Y9CYZr+teTTWLVzPm/GyJ/EQOJvIhZ 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:(13230022)(136003)(366004)(39860400002)(396003)(346002)(376002)(451199015)(186003)(26005)(53546011)(122000001)(52536014)(8936002)(6506007)(30864003)(55016003)(9686003)(7696005)(66946007)(5660300002)(33656002)(66446008)(66556008)(66476007)(6916009)(64756008)(316002)(38070700005)(86362001)(71200400001)(76116006)(38100700002)(82960400001)(478600001)(41300700001)(8676002)(83380400001)(2906002)(2004002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?72a+bE9vruMAdCKDRRqt+S8UZdC3s4TUKwbNgH765h0f62e/DJ+sI9xDi0NR?= =?us-ascii?Q?mOLuQQleb9XGdkfiXHIuOYzhPhCrAWErE+UdqIyOdGVz3J8hQ5rYF5WMReho?= =?us-ascii?Q?8g/FxCg1rN7MUuqXfiPInz0R/S2V0BKn8+/aOZLMVGju0Cm2ZRn0lH7GpxK8?= =?us-ascii?Q?85cBC91SJX8HYOJQr1J1+KafLuOZ/kJshLpwMvS4BvjFg26g1x8OEHIpKiba?= =?us-ascii?Q?AYatzXzk/wbSgVS7SpgjjUvWj1N1fRweZI5dJyRdBScHM48uI5JTVglBe8yp?= =?us-ascii?Q?DjO28QKNZEZ7gcuCsYWZmqMlXJdRrJOpINMkR0AljsHNB/WbOkabn9dAyAHC?= =?us-ascii?Q?QuhMxrSrl3a8ote2eXZkEtn/RYKy0jLOd3LrbW1+kEosgzxQdPUVrvLv2Qke?= =?us-ascii?Q?6RKOG6NPdclxYnq9L8vQrPvVWzpK4q3MVaKY01eJH4rc9dyjFKu2I24GleZW?= =?us-ascii?Q?P/3LFIb99lB7J4jregjkZeKPpY0X1oznM0pZQRMYoaw+c5wfdh970rYPGW6E?= =?us-ascii?Q?H65r88dIuAwPTLXotOhS2zkFGwCSbz6BuwidN0O1IWsqZ5e/PJuGH8je6zC8?= =?us-ascii?Q?LbOPrHi0iliuXJUVBASAEK1B/cinGTs7qPVFRGxf/gVsxw/ZX42lwDvQ9JsA?= =?us-ascii?Q?1dAm8+vOBv+gpy7MOAHBUkdwrnLWOhR8N1cRiM8IDfXNHn1KyegBDh7tZpUT?= =?us-ascii?Q?5dcA66DWU7fbcCqx6CzVVvE/aSFVeRMM+8GOz9t8dOpYBvm7EyOZHMOBVcn/?= =?us-ascii?Q?aSy983Wp0qDz2nXM2FP09aClXqhQ36XindaemjErnTBdb8QQ5YD+x5ScLIe8?= =?us-ascii?Q?yD/Ct4xEj36F7peTAplmw/z8rzdzMCKD+Xv66HQG4qYLwOFuZtkWjJOC4V/Q?= =?us-ascii?Q?Itldi9ZdhdQLItu4IxuL29MhYL3Yabr00yN2hiiwQ/pNn/TzRtdRWB8DSnON?= =?us-ascii?Q?KzOHN6xv4ILNJyNJbQEafGp9xgdlZwbPRSnsbKqBXK6/Y/PDcJJ6zQNO9+qz?= =?us-ascii?Q?XtZA9SKpQHzXZMeAhpZyWhCbqNwWypvYzXiOxOEjrM1TLAc8fjG7U8zjF7Tq?= =?us-ascii?Q?WICvo8Hxuba2cJVNcyPJQnjOQIbpIlj7QAGTAMd6nZ+mlC2RjiV0whCcSzcV?= =?us-ascii?Q?WkqfSzRnoxOERKdZmq7eFUEwlSGAVBN1eYme2pHKqXQt9u5KQsQYYOIOR9u9?= =?us-ascii?Q?gJG1stCuDmr2GgcOKDB4HwzLVruxhFnzGzPe9qoMgx1Gxx8LOFDlPt9OVpDj?= =?us-ascii?Q?vfGwMhJ75lyFJd7rPMqCxwQ+p+hNP5bXZ8tBLSJNVnWcE0vrILQKBvxwZaVr?= =?us-ascii?Q?7JYTVG099DzHcOxLT0RhV6JKwyrUNn/815h9GGLzoATDckL1D1hFU17qzCpx?= =?us-ascii?Q?0l5244bidESNGozP/Cv54gHl3ge66xD2Ivj/EkDeAKWCKWDPAG9t2B4Qkv9R?= =?us-ascii?Q?OH/9PqCM4xdDU7VA2MstRDG2HQzUf3x7W8lmT/sgqOaZkn5jjReMyRSEGQvj?= =?us-ascii?Q?ZZlJ6FnSJQxqORvpE9f0fFgLnIXeVGRMjez5pbQsTNIc+mr1nPlSVZWgDjlX?= =?us-ascii?Q?sV6Mhm6cENGrSIDmwcnRFnhQ9xf9yqS09f1NBJnwREjK85cnqSVxcdYNE1iT?= =?us-ascii?Q?Bg=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: 3ee867dc-c3ba-481a-39b0-08daf34dbd5b X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2023 21:00:44.0937 (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: pAUCaC/bL4miDfxAsDz5Yn3frjIgJ9/37UP83u1s/uSI4JrpljSsOYxVND0mbE0tgPYvuoJbWcTPgbwnXVQeuQsGNFmf6e7ewg90jrQ/0VA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6380 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,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 List-Id: Kindly pinging. Thanks -Baris On Wednesday, November 16, 2022 7:56 PM, Aktemur, Tankut Baris wrote: > Suppose we have two inferiors on an all-stop target with schedule-multi > set on: > = > $ gdb -q > (gdb) target extended-remote | gdbserver --multi - > Remote debugging using | gdbserver --multi - > Remote debugging using stdio > (gdb) file /temp/test > Reading symbols from /temp/test... > (gdb) set remote exec-file /temp/test > (gdb) start > Temporary breakpoint 1 at 0x115c: file test.c, line 8. > Starting program: /temp/test > stdin/stdout redirected > Process /temp/test created; pid =3D 864027 > ... > = > Temporary breakpoint 1, main (argc=3D1, argv=3D0x7fffffffd218) at test.= c:8 > 8 foo(); > (gdb) add-inferior > [New inferior 2] > Added inferior 2 on connection 1 (extended-remote | gdbserver --multi -) > (gdb) inferior 2 > [Switching to inferior 2 [] ()] > (gdb) file /temp/test > Reading symbols from /temp/test... > (gdb) set remote exec-file /temp/test > (gdb) tbreak 2 > Temporary breakpoint 2 at 0x555555555131: /temp/test.c:2. (2 locations) > (gdb) run > Starting program: /temp/test > stdin/stdout redirected > Process /temp/test created; pid =3D 864430 > ... > = > Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2 > 2 int a =3D 42; > (gdb) set schedule-multi on > (gdb) > = > At this point, detaching the first inferior works fine: > = > (gdb) detach inferiors 1 > Detaching from program: /temp/test, process 858904 > Detaching from process 858904 > [Inferior 1 (process 858904) detached] > (gdb) info inferiors > Num Description Connection Exec= utable > 1 1 (extended-remote | gdbserver --multi -) /tem= p/test > * 2 process 858925 1 (extended-remote | gdbserver --multi -) /tem= p/test > (gdb) > = > Let us now repeat exactly the same scenario, but before detaching, we > make the current thread single-step an instruction: > = > ... > Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2 > 2 int a =3D 42; > (gdb) stepi > 3 int b =3D 43; > (gdb) detach inferiors 1 > Detaching from program: /temp/test, process 876580 > Detaching from process 876580 > gdbserver: Couldn't reap LWP 876580 while detaching: No child processes > [Inferior 1 (process 876580) detached] > (gdb) 3 int b =3D 43; > = > There is a mysterious line info output. Running the scenario with > infrun debug logs reveals more information. > = > ... > Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2 > 2 int a =3D 42; > (gdb) stepi > 3 int b =3D 43; > (gdb) set debug infrun on > (gdb) detach inferiors 1 > [infrun] scoped_disable_commit_resumed: reason=3Ddetaching > Detaching from program: /temp/test, process 872445 > Detaching from process 872445 > gdbserver: Couldn't reap LWP 872445 while detaching: No child processes > [Inferior 1 (process 872445) detached] > [infrun] start_step_over: enter > [infrun] start_step_over: stealing global queue of threads to step, l= ength =3D 0 > [infrun] operator(): step-over queue now empty > [infrun] start_step_over: exit > [infrun] restart_stepped_thread: switching back to stepped thread (step= ping) > [infrun] keep_going_stepped_thread: resuming previously stepped thread > [infrun] keep_going_stepped_thread: expected thread advanced also (0x55= 5555555131 -> > 0x555555555138) > [infrun] clear_step_over_info: clearing step over info > [infrun] do_target_resume: resume_ptid=3D-1.0.0, step=3D0, sig=3DGDB_SI= GNAL_0 > [infrun] infrun_async: enable=3D1 > [infrun] reset: reason=3Ddetaching > [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed = for target > extended-remote > [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed = for target > extended-remote > (gdb) [infrun] fetch_inferior_event: enter > [infrun] scoped_disable_commit_resumed: reason=3Dhandling event > [infrun] do_target_wait: Found 2 inferiors, starting at #0 > [infrun] random_pending_event_thread: None found. > [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1],= status) =3D > [infrun] print_target_wait_results: 872464.872464.0 [Thread 872464.= 872464], > [infrun] print_target_wait_results: status->kind =3D STOPPED, sig = =3D GDB_SIGNAL_TRAP > [infrun] handle_inferior_event: status->kind =3D STOPPED, sig =3D GDB= _SIGNAL_TRAP > [infrun] context_switch: Switching context from 0.0.0 to 872464.87246= 4.0 > [infrun] handle_signal_stop: stop_pc=3D0x555555555138 > [infrun] handle_signal_stop: [872464.872464.0] hit its single-step br= eakpoint > [infrun] handle_signal_stop: delayed software breakpoint trap, ignori= ng > [infrun] process_event_stop_test: stepi/nexti > [infrun] stop_waiting: stop_waiting > 3 int b =3D 43; > [infrun] infrun_async: enable=3D0 > [infrun] reset: reason=3Dhandling event > [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-= resumed for target > extended-remote, no resumed threads > [infrun] fetch_inferior_event: exit > = > GDB attempted to do a step-over for the current thread. This takes us > to the commit that introduced restarting step-overs: > = > commit 408f66864a1a823591b26420410c982174c239a2 > Author: Pedro Alves > Date: Mon Jan 11 20:01:58 2021 +0000 > = > detach in all-stop with threads running > = > A following patch will add a testcase that has a number of threads > constantly stepping over a breakpoint, and then has GDB detach the > process, while threads are running. If we have more than one inferior > running, and we detach from just one of the inferiors, we expect that > the remaining inferior continues running. However, in all-stop, if > GDB needs to pause the target for the detach, nothing is re-resuming > the other inferiors after the detach. "info threads" shows the > threads as running, but they really aren't. This fixes it. > = > However, the thread that was resumed for step-over in our scenario did > not have an interrupted step-over; it had completed its stepi already. > More debugging reveals that the thread is resumed because of the > following two conditions in `restart_stepped_thread`: > = > if (tp->control.trap_expected) > { > infrun_debug_printf ("switching back to stepped thread (step-ov= er)"); > = > if (keep_going_stepped_thread (tp)) > return true; > } > = > and > = > if (tp->control.step_range_end) > { > infrun_debug_printf ("switching back to stepped thread (steppin= g)"); > = > if (keep_going_stepped_thread (tp)) > return true; > } > = > The root cause of the problem is, the 'trap_expected' and the > 'step_range_end' fields of the thread's control remain set even after > the "stepi" command completes. We fix the problem by clearing the > control fields when stepping completes. We also add a regression test. > = > Regression-tested using the default, native-gdbserver, and > native-extended-gdbserver board files. > --- > gdb/infrun.c | 3 ++ > gdb/testsuite/gdb.multi/detach-stepi.c | 30 +++++++++++ > gdb/testsuite/gdb.multi/detach-stepi.exp | 66 ++++++++++++++++++++++++ > 3 files changed, 99 insertions(+) > create mode 100644 gdb/testsuite/gdb.multi/detach-stepi.c > create mode 100644 gdb/testsuite/gdb.multi/detach-stepi.exp > = > diff --git a/gdb/infrun.c b/gdb/infrun.c > index 6da46b75ac7..ef422f0e9e9 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -8314,6 +8314,9 @@ static void > end_stepping_range (struct execution_control_state *ecs) > { > ecs->event_thread->control.stop_step =3D 1; > + ecs->event_thread->control.trap_expected =3D 0; > + ecs->event_thread->control.step_range_start =3D 0; > + ecs->event_thread->control.step_range_end =3D 0; > stop_waiting (ecs); > } > = > diff --git a/gdb/testsuite/gdb.multi/detach-stepi.c b/gdb/testsuite/gdb.m= ulti/detach-stepi.c > new file mode 100644 > index 00000000000..d365645fb3f > --- /dev/null > +++ b/gdb/testsuite/gdb.multi/detach-stepi.c > @@ -0,0 +1,30 @@ > +/* This testcase is part of GDB, the GNU debugger. > + > + Copyright 2022 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 .= */ > + > +void > +a_function () > +{ > + int a =3D 42; > +} > + > +int > +main () > +{ > + int b =3D 43; > + a_function (); > + return 0; > +} > diff --git a/gdb/testsuite/gdb.multi/detach-stepi.exp b/gdb/testsuite/gdb= .multi/detach- > stepi.exp > new file mode 100644 > index 00000000000..28ef8c4f9f7 > --- /dev/null > +++ b/gdb/testsuite/gdb.multi/detach-stepi.exp > @@ -0,0 +1,66 @@ > +# This testcase is part of GDB, the GNU debugger. > + > +# Copyright 2022 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 . > + > +# Test detaching from an inferior after a thread in another inferior > +# completes a stepi. This is a regression test for a bug that was > +# causing an inadvertent resume of the just-stepped thread. > + > +standard_testfile > + > +if {[use_gdb_stub]} { > + untested "using gdb stub" > + return 0 > +} > + > +if {[prepare_for_testing "failed to prepare" $testfile $srcfile]} { > + return -1 > +} > + > +if {![runto_main]} { > + return -1 > +} > + > +delete_breakpoints > + > +# Setup inferior 2. > +gdb_test "add-inferior" "Added inferior .*" \ > + "add empty inferior" > +gdb_test "inferior 2" "Switching to inferior .*" \ > + "switch to inferior" > + > +gdb_load $binfile > +runto "a_function" > +gdb_test "info inferiors" > + > +# The bug for which this regression test is written appears in > +# schedule-multi mode. > +gdb_test_no_output "set schedule-multiple on" > + > +# Single-step the thread in Inferior 2, then detach Inferior 1. > +gdb_test "info threads" ".*" "threads before stepi" > +gdb_test "stepi" > +gdb_test "info threads" ".*" "threads after stepi" > + > +gdb_test "set debug infrun on" > +gdb_test_multiple "detach inferior 1" "" { > + -re "resuming previously stepped thread.*$gdb_prompt" { > + fail $gdb_test_name > + } > + -re "$gdb_prompt $" { > + pass $gdb_test_name > + } > +} > -- > 2.25.1 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