From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8ZGhIhC9nmqwJzQAWB0awg (envelope-from ) for ; Mon, 07 Sep 2026 09:33:04 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=epdPcj0d; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 86D081E09E; Mon, 07 Sep 2026 09:33:04 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 8A4B51E091 for ; Mon, 07 Sep 2026 09:33:02 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E6DA64BC7EF1 for ; Mon, 7 Sep 2026 13:33:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E6DA64BC7EF1 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=epdPcj0d Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by sourceware.org (Postfix) with ESMTPS id 7C61D4BA2E12 for ; Mon, 7 Sep 2026 13:32:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7C61D4BA2E12 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 7C61D4BA2E12 Authentication-Results: sourceware.org; arc=fail smtp.remote-ip=192.198.163.9 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1788787947; cv=fail; b=MdEYTsleT/XYQDCP+uv1IT6veFZitoKjqINnFXsRmCLCxDrwS9tQZSS6ngroSTOQTOcdnx0CX+zE6u6pd8Kz8z6G0WDr0B/Y6zHGQ5/7EupAmiFssCqCT45+opdymMZotxj9QmRnvyWPdfZjBcgFg3lrVhoFH1X7WAriigjHBKM= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1788787947; c=relaxed/simple; bh=xfMZ0QGAmlBeJhGHRhE95WyDMC79RKReuO/kPdixXfU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=J8FLnfF8Dc3FvffZbt47cRV4VW103/LyrhoWBMUXCcQBs69ebIjK1uw6f1I80L6MK+x0TiInfWK05o1WyQEV0Qzdf9gh6JbmTXuMYrd2B8Q3kNT0Py+BNvtzeThqKcwKu7bXZ1rpVGwmCgCeCpcylKd+dGzGLtDjWOgM/eRHeJE= ARC-Authentication-Results: i=2; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=epdPcj0d DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7C61D4BA2E12 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1788787948; x=1820323948; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xfMZ0QGAmlBeJhGHRhE95WyDMC79RKReuO/kPdixXfU=; b=epdPcj0dfho88OUFlvxSNYAsThfKE2uTar0yIhx+d4SiAlz0CK8gTTMw wPGpj0drwFNZ/BmgfFmByb38GLcw2IvODmxVPdUYawhGuzyuTkr3OJpfU 2Oc8fQ1l0L+iHUy7gLSjwYdJYHl3qTlOdhEcI2l5DYAxmp9BC5xeSvtCO m532xY7BaUSepE+7bwhEKF3N+xxXSoX1Bo6N8es6GBv5U3KuYhg5LBPQY TN7A5lVTbzfBHrW6J8aTCHnyBzaPd3+/75cbnT0vkStwVsLJNLTMJJ16r hoYuR4QgFLv0FGjp8SqYTkmjmRuG4d+FIFHCAHJa+LVfBB9y54Ef74coz A==; X-CSE-ConnectionGUID: r3nIvlpvQluTr0i6XLoydA== X-CSE-MsgGUID: hosxqEc1SVaUKK0S/LtsYA== X-IronPort-AV: E=McAfee;i="6800,10657,11898"; a="99849756" X-IronPort-AV: E=Sophos;i="6.25,267,1779174000"; d="scan'208,217";a="99849756" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2026 06:32:26 -0700 X-CSE-ConnectionGUID: 3iTf+rOUS0aSNNJN2T0qVA== X-CSE-MsgGUID: nlcUsYVMQtmWFP9uVydGZw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,267,1779174000"; d="scan'208,217";a="270189356" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by orviesa008.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2026 06:32:26 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Mon, 7 Sep 2026 06:32:25 -0700 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46 via Frontend Transport; Mon, 7 Sep 2026 06:32:25 -0700 Received: from CH5PR02CU005.outbound.protection.outlook.com (40.107.200.62) by edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Mon, 7 Sep 2026 06:32:22 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GhTdrYPjQwyPqdsp/Lhu0U3xj51PdFR8pftKguTeYr3pcSpj7YUOoGL3Q43nYb49kCxOROKh1xWqNkpWcuqoXMCCh+253mNqEusiDaGULguvLTcVGkvCD1yJFh21ABF6VXgDqUdlu47l0jmdEDRp2ttjPXpQwl9T/K1XUwSH9GG8zWNNemy4VL4+yUr42jB6aJiDXBmT3vKBhDZJ/xY+1l6s23B+t8KEwTm0gmnwr6XdCZfASTJFy8me+QIlG4ou3VtDscV6RKrTx8xzQNdNFS3TRYqKYCOJ/247OS84tBUX8z3POX3RDNpSvnO79FneHbXrFlo70JhFGW7LIGJPxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=1eQFgv/ow0fC+vNw0nX77CLOFdOHCvvXgzruzDkavBc=; b=pUI/Zb7MYmmjH2eslevlrGneqwPZraAUzSWDzC7McQuVh4VqRdtx6ySfl6b4QCL3uAGZ48dbElZQyshsKi7n44wm9Adr0wF/mAW1eqEqNPpsSg/TfbfhcnhDe9UcdxMRIk3p5pli/41FiJwXTHvjd9B7t5ZHl3mAY0JBHjLP96SX29E/B21TyBesM05rSWRxVg131/8mYkIlL1QEI+8R02C6Yom/KJOuw0jRTV7FlneWfH7f7wSUq2U62p/SGG3dtjJMI6Ynu0+9TRZnlo3hANRnHZm0BpGtlIgcPzYZNPzpUglQCh4C8giFuhuxm/tkc5OBUzfCWXjSaWZce75dBQ== 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 SA1PR11MB6968.namprd11.prod.outlook.com (2603:10b6:806:2be::22) by SA1PR11MB8393.namprd11.prod.outlook.com (2603:10b6:806:373::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.8; Mon, 7 Sep 2026 13:31:58 +0000 Received: from SA1PR11MB6968.namprd11.prod.outlook.com ([fe80::ab18:2ee7:3448:d71a]) by SA1PR11MB6968.namprd11.prod.outlook.com ([fe80::ab18:2ee7:3448:d71a%7]) with mapi id 15.21.0382.012; Mon, 7 Sep 2026 13:31:58 +0000 From: "Bouhaouel, Mohamed" To: Pedro Alves , Tom Tromey CC: "gdb-patches@sourceware.org" , "Metzger, Markus T" , "Rohr, Stephan" , "eliz@gnu.org" , "aburgess@redhat.com" Subject: Re: [PATCH v4 00/11] Add AlwaysNonStop remote protocol extension Thread-Topic: [PATCH v4 00/11] Add AlwaysNonStop remote protocol extension Thread-Index: AQHdPJeRb2AknnvFj06UR/EPF1H3Aba+xHwAgARWpBo= Date: Mon, 7 Sep 2026 13:31:58 +0000 Message-ID: References: <20260714092128.12941-1-mohamed.bouhaouel@intel.com> <87jyp028ux.fsf@tromey.com> <42bc9fd0-1396-494e-b7af-a5af10a94172@palves.net> In-Reply-To: <42bc9fd0-1396-494e-b7af-a5af10a94172@palves.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: 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: SA1PR11MB6968:EE_|SA1PR11MB8393:EE_ x-ms-office365-filtering-correlation-id: ce91e890-f9b0-445d-c3af-08df0ce46411 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|1800799024|23010399003|376014|22082099003|18002099003|13003099007|3023799007|8096899003|38070700021|11063799006|56012099006|10067099003|4143699003; x-microsoft-antispam-message-info: 46pctfqTcIHqRBFLpFZX/wk54tpS8jzG4EW0DZT8w+ja9EsZ9FKHK5ae4/NmTnTXyzXl89qk8JB+gvTRfrF6RYHiXb9ehtHy86k0zfiIC1A048kIuX1MtUsRoogA0kg57SrYVC+pXnBE9k3hf4GO1kiPNgaul2lMtlzng+g9VDRHcjiXgjOxYNywBWgneKWXWsGUbc164jkb4HnmdhjwfhHne9Q2yh3hihXqWmuZTBqIjUED+m5GOIOz637YA1cgVEpEH5d5JAD5BlOGje8PUQaqz9ATkESXmF3NljaxKQcuHfYYLUCTKDz3Ark+l4NrzKceAaWKa3VNvtWS2VgZi9BJgz2iA4lrJoVc2YgzbpGRO/CoVTgqJ4Nsafoe33RKriE1D4i0ACRMJIG40KzgwPpc3GBbHj3Qhb7i9W6WVrinuX/apmI80XLblnxBV9uX03yyJxYE8rG23cpF6MVVPpcFywufhXVOY4ky3E7A6GRdcWxcwrg2ZQh+alNHuw5M2QbHAc+v259pFW5xup6RUV8VVYCxtmJdFhAk7oS99iufR264B70WO2DbqN5una6DjtKjkPktV5Q73PiM6sAn1NyLZwBDNM7s4grnQI/6Wv1r8JSNTEbdeorgKbq6qz5zQS4KsznBDGBH8k4TFyhly6hcH5r4Ii+5Qp4dIfauwKXNOG9j9nO+/A3czalINIYb9Q4pMC9HMCOkdJDr/ulOHegN6/3sspfQFh3RuTdqIP8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR11MB6968.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(22082099003)(18002099003)(13003099007)(3023799007)(8096899003)(38070700021)(11063799006)(56012099006)(10067099003)(4143699003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TuaXAwbNrYWPw6wXpaNDfaYZ/sBRHBVtDLto7AME8Fz2BEyekaHIeVXcuL?= =?iso-8859-1?Q?BKuJ5l+Pf6uIZJblRNQiBu9RCoRS6rPAOP8eWgXFryqeNopZRTgKflCyNP?= =?iso-8859-1?Q?Cp6/i7zT2bo3FIlc6LomB88NNUQUgar9RWwyCATpS4HzlQPiFxwN5Ht4Wt?= =?iso-8859-1?Q?PZ3W153M3lMmQTLI3KZBm2Ybp92DiHSeZe5oVJ+NP1Q9azNkP38m0WvwOa?= =?iso-8859-1?Q?vIsRqOBpu8T3ceX9SPbH8gHSvwnB8sGdypvImdA6/vu4RjEbgeroiD5mbT?= =?iso-8859-1?Q?3/SlI73h3eDFCZ6Zo5bkA6UjkJEWNJzb9Bc8CHUU4tyJfGsw1vZQhIa56m?= =?iso-8859-1?Q?VPGf9ew+RDI90y8wpgAaeEtITXxtcH3h5ZewwIRoVm6yf0HRP9OcEkdEln?= =?iso-8859-1?Q?2lrnh+JjnFbdceD/Fr/iQoXc47sBl/XL9Cg3WSVI+gTOXbrub5jDIFiNC9?= =?iso-8859-1?Q?BZvJP6/s2Umb1EoPOXPWXrynqgzOvKc19OrH1Ry1kqgCtlefsf5cjqFnT9?= =?iso-8859-1?Q?2rAqtLZ9qqQbKz6ZZ+/wqv/90QFtiF0nLVTS7n3ai3EB1csPFITpFQW+9S?= =?iso-8859-1?Q?f4mU9QNYWuOPdojtqWJ4x4SSBdXQkDnuZFDEwlTvxkLI94RPffHd9qJg62?= =?iso-8859-1?Q?WmuTcvNCbSArGIMQy+x+K88Dk3NRmH5XOKivBlIzBpi3eQQp/gJMrvMknf?= =?iso-8859-1?Q?RxDapnDcDbFQe6YjCDSxp1tOA2Tei2zKQOAuRMZbcXcnj0tD0OInH/NbAm?= =?iso-8859-1?Q?IYmmRUuFKTSI26QU3Tb5p+wVeVxYFp6to5EYefsGOBtCrC4JLRFG2xAMyp?= =?iso-8859-1?Q?GmwpVFaZhncNzhxQ/YTnETonGN/PbiDZPVFFuQXUHYResMX30QC9F4ZoG6?= =?iso-8859-1?Q?MPWPc7AjgmAmaLUa4oHsaLIDV13BdgoBbf4TQLkm5GVtd1ZRacr3n+jzbT?= =?iso-8859-1?Q?NJnowFrVYPjQA2Fz4V+mTq89gtsV0WpSORlM29cftgej8ptw1BDoTduRmf?= =?iso-8859-1?Q?zEwx8Zy8N6t/pLKUQRjojopJae8eAmd0NRCRdP9O/jgCleVgEnqf5zsSkj?= =?iso-8859-1?Q?MaZUAiBiThrwLXbuUDHT0XwxLEcZ0WDVIW1K7jRfTHWpDAq2rM7FjAVdd+?= =?iso-8859-1?Q?QanOeiMswpzGX1H/jmYG4arPAIzWOfBgmW74kGRe4QKy1FpjhSDkVM+kmS?= =?iso-8859-1?Q?C+5wACzJhtNF6r0wYOm1nDdECBtYbO1qArOidpPhY9SY1XU7GoQdxhSmRn?= =?iso-8859-1?Q?kQa89HcHRtAXEult753pwXha6p0NwUkKeoOEgp1Vw82NUQmH7yRrgS+3oa?= =?iso-8859-1?Q?tcZ3zm/8DX91ToUchhcOdaaA/kC3pJiMwQHso7EHK4InxTTFa5wtexMaE1?= =?iso-8859-1?Q?/HQGlTqPzU/iuxeZa4Tl/wmfLBaVXQY65F0ZgDQuACRWOblcsXBrwQpvzi?= =?iso-8859-1?Q?6QByplQccDIQLtMLLEEBOSXfm1OAJaADdRDUWBd16cNfU+ObMD0V3EngSo?= =?iso-8859-1?Q?xs/I8sosKm9GUMpr1BS75ZE3wVHR2igzAme9it0F520nfdZWDdIbGr0UcC?= =?iso-8859-1?Q?4rlgodsJ2XofduMfvJMANAMAfkWrRYpea3Jxhs9GLp3cjTcYnq9R6JsPpJ?= =?iso-8859-1?Q?w6D0WEmaDyj8f5IAjjFADpVIDjAVqisMKbaML0zGMpCIR3Fg5BzHS57JV7?= =?iso-8859-1?Q?Wi1d+/dlNcdOtz5o1tHevC6BSeyhTT23fM3me1mJ/kIbxJg/uTvrdRLoan?= =?iso-8859-1?Q?GVwB+g2cSpz+9i7TPbAC0TK9xp9Q49d9mfORLd03yqN+m4g2/iN40sX3fD?= =?iso-8859-1?Q?zqIlrPT2DQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SA1PR11MB6968E08258D1B994F35D1785E4B22SA1PR11MB6968namp_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: z2AAdHIy3TE93GpaM3WNJAMhZ0aB65LDk808BohnipHP1/8szkbjuJ549gWUU/r8/lggt07mnW27W7PtKwiwiMteC0U3Mw6wUW5Z1+ROj4J1JEovIdKm7nWycJuIHXKDOPkzq06vCX67TMnmyHuEus0n8ZWr+x3dF715PSaxbzShp/LalsvpiXntVLJW140CSE8eqohKHhZVE4vd+roetOazpnIrfSD5ZcVdwJgwSrQCQ8t3PV+hV7v02zvOreTZm8isMjXdpN32wshKzt5kFye1TT1Gjun9gheX0eGRgULxO3JUq/zCVx25ir2pvZLalY+/28cGNJxLSFZZsmwcaw== X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB6968.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce91e890-f9b0-445d-c3af-08df0ce46411 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2026 13:31:58.0341 (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: tauW2WBaFRpTYLYmNChWapRL18LKw6i2F1/bczRgh/1iEfIWOYKmOn6S00XdlMWHOq8DUa1M0hO/Jh3Z7o5WYKRxRRcIzXcaT/g6+z5Aj8M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB8393 X-OriginatorOrg: intel.com X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org --_000_SA1PR11MB6968E08258D1B994F35D1785E4B22SA1PR11MB6968namp_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks, Tom, for looking into this. Thanks, Pedro, for the context and for planning to review it. The summary captures the motivation well. Note that intel has already posted the fundamental GPU debugging support for review https://inbox.sourceware.org/gdb-patches/20260812132805.380163-1-mar= kus.t.metzger@intel.com/. Looking forward to receiving your feedback. --Mohamed ________________________________ From: Pedro Alves Sent: Friday, September 4, 2026 8:54 PM To: Tom Tromey ; Bouhaouel, Mohamed Cc: gdb-patches@sourceware.org ; Metzger, Marku= s T ; Rohr, Stephan ; e= liz@gnu.org ; aburgess@redhat.com Subject: Re: [PATCH v4 00/11] Add AlwaysNonStop remote protocol extension On 2026-09-04 19:02, Tom Tromey wrote: >>>>>> Mohamed Bouhaouel writes: > >> This series introduces the AlwaysNonStop extension, enabling remote >> stubs to declare preferable non-stop mode operation. When advertised, >> GDB defaults to non-stop mode. Attempts to disable it might be rejected >> by the stub with a descriptive error message. > > One thing I don't see in the series is the motivation for this. > It doesn't seem like something that would be useful to a user. > > And if a server wants to work in all-stop-on-top-of-non-stop mode, > I don't think there's really anything preventing that; but also this > wouldn't require any kind of protocol extension. > > I looked at this a little but I'm perhaps not the best person to review > it. I can take a stab at some of it at some point; but I would like to > understand the purpose. > FWIW, I discussed the design that led to this with Mohamed and others off-l= ist, and I do plan to review it once I'm able. I'll try to give it a shot next = week. The main purpose is that Intel's GPU support is designed as combining two inferiors, one for the CPU side, and one for the GPU side. The CPU side is a standard linux-nat target, which runs in all-stop-on-top-of-non-stop (= AS-NS). The GPU side is based on a remote gdbserver connection. Combining a non-stop (native) with an all-stop (remote/gdbserver) target is something that infrun is not really prepared for. So I've suggested that i= nstead, it'll be better if Intel's gdbserver always works in non-stop mode, too. There is really currently no way for the server to tell GDB that it wants t= o work in that way. Users would have to set "maint set target-non-stop on" manual= ly. AS-NS on the remote side has some user-visible advantages. The AS variant = of the protocol doesn't let you talk to the remote side until the target next stop= s, for example. so no setting breakpoints, no reading global variables, etc., non= e of that is possible while the target is running, while it is, in AS-NS. The main diff= erence is that vCont is asynchronous in the non-stop remote protocol. So ideally,= we'd switch over to that variant when we can, by default. But since there are limitations (the ones I listed in the discussion of a previous revision of = this series), a remote target reporting that is supports non-stop mode, should not be tak= en as meaning that it prefers to use non-stop mode by default. That's what the new exten= sion gives us, a way for the remote target to tell GDB what it wants. I ran out of time this week, but I'll try to look at this soon. And of cou= rse, others shouldn't be discouraged from looking just because I said I would. The mor= e eyes, the better. Pedro Alves ________________________________________ Intel Deutschland GmbH = Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany = Tel: +49 (89) 99143-0 = www.intel.de = Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitar= aman Chairperson of the Supervisory Board: Sonja Pierer Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_SA1PR11MB6968E08258D1B994F35D1785E4B22SA1PR11MB6968namp_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Thanks, Tom, for looking into this. Thanks, Pedro, for the context and for<= /div>
planning to review it.  The summary captures the motivation well.

Note that intel has already posted the fundamental GPU debugging support fo= r
review https://inbox.sourceware.org/gdb-patches/20260812132805.380163-1-markus.t.m= etzger@intel.com/.

Looking forward to receiving your feedback.

--Mohame= d

 



From: Pedro Alves <pedro@palves.net>
Sent: Friday, September 4, 2026 8:54 PM
To: Tom Tromey <tom@tromey.com>; Bouhaouel, Mohamed <mohame= d.bouhaouel@intel.com>
Cc: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; M= etzger, Markus T <markus.t.metzger@intel.com>; Rohr, Stephan <step= han.rohr@intel.com>; eliz@gnu.org <eliz@gnu.org>; aburgess@redhat.= com <aburgess@redhat.com>
Subject: Re: [PATCH v4 00/11] Add AlwaysNonStop remote protocol exte= nsion

On 2026-09-04 19:02, Tom Tromey wrote:
>>>>>> Mohamed Bouhaouel <mohamed.bouhaouel@intel.com&= gt; writes:
>
>> This series introduces the AlwaysNonStop extension, enabling remot= e
>> stubs to declare preferable non-stop mode operation.  When ad= vertised,
>> GDB defaults to non-stop mode.  Attempts to disable it might = be rejected
>> by the stub with a descriptive error message.
>
> One thing I don't see in the series is the motivation for this.
> It doesn't seem like something that would be useful to a user.
>
> And if a server wants to work in all-stop-on-top-of-non-stop mode,
> I don't think there's really anything preventing that; but also this > wouldn't require any kind of protocol extension.
>
> I looked at this a little but I'm perhaps not the best person to revie= w
> it.  I can take a stab at some of it at some point; but I would l= ike to
> understand the purpose.
>

FWIW, I discussed the design that led to this with Mohamed and others off-l= ist,
and I do plan to review it once I'm able.  I'll try to give it a shot = next week.

The main purpose is that Intel's GPU support is designed as combining two inferiors, one for the CPU side, and one for the GPU side.  The CPU si= de
is a standard linux-nat target, which runs in all-stop-on-top-of-non-stop (= AS-NS).
The GPU side is based on a remote gdbserver connection.

Combining a non-stop (native) with an all-stop (remote/gdbserver) target is=
something that infrun is not really prepared for.  So I've suggested t= hat instead,
it'll be better if Intel's gdbserver always works in non-stop mode, too.

There is really currently no way for the server to tell GDB that it wants t= o work
in that way.  Users would have to set "maint set target-non-stop = on" manually.

AS-NS on the remote side has some user-visible advantages.  The AS var= iant of the
protocol doesn't let you talk to the remote side until the target next stop= s, for
example.  so no setting breakpoints, no reading global variables, etc.= , none of that is
possible while the target is running, while it is, in AS-NS.  The main= difference
is that vCont is asynchronous in the non-stop remote protocol.  So ide= ally, we'd
switch over to that variant when we can, by default.  But since there = are
limitations (the ones I listed in the discussion of a previous revision of = this series),
a remote target reporting that is supports non-stop mode, should not be tak= en as meaning
that it prefers to use non-stop mode by default.  That's what the new = extension gives us,
a way for the remote target to tell GDB what it wants.

I ran out of time this week, but I'll try to look at this soon.  And o= f course, others
shouldn't be discouraged from looking just because I said I would.  Th= e more eyes,
the better.

Pedro Alves

____________= ____________________________

Intel Deutsc= hland GmbH

Registered A= ddress: Dornacher Strasse 1, 85622 Feldkirchen, Germany

Tel: +49 (89) 99143-0 =

= www.intel.de

Managing Directors: Candice Moore= , Jeffrey Schneiderman, Ramachandran Sitaraman

Chairperson of the Supervisory Bo= ard: Sonja Pierer

Registered S= eat: Munich Commercial Register B: Amtsgericht Munich HRB 186928

This e-mail and any attachments m= ay contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_SA1PR11MB6968E08258D1B994F35D1785E4B22SA1PR11MB6968namp_--