From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id eIA+N/uHemisqhcAWB0awg (envelope-from ) for ; Fri, 18 Jul 2025 13:44:27 -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=TM4CcErw; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DD99F1E11C; Fri, 18 Jul 2025 13:44:27 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-10.1 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 546C51E089 for ; Fri, 18 Jul 2025 13:44:26 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 08573385141C for ; Fri, 18 Jul 2025 17:44:26 +0000 (GMT) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) by sourceware.org (Postfix) with ESMTPS id 8F0303860002 for ; Fri, 18 Jul 2025 17:43:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8F0303860002 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 8F0303860002 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=192.198.163.14 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1752860616; cv=fail; b=P6/XV0m+bM5c+GR74ltLHR29nZHntCeRxLW78Q7CI/iHDNj4Yb740ZrAcOI+CF10YglfTFZKdrSPbugWXyc1PIJ6DPFF43PP4bVHLw1Hg4l9qbIQkChyM6euLgzmfF/XuEt7ftKexEEkm08G8avWXFHbJkv3L6wfEkLF1dQ9xPM= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1752860616; c=relaxed/simple; bh=bzUa3QiT/s07stUG4qTVIJAqfOBc12CHNg7HB5paDSg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=PsOX5bMVN7K22YkT97sRttNqUyS3Ga6wxcIu43RSspVsmSFnxD3iltYSAtyKVVywMjwENR1Ob9Yk62jWissvb+UyxdQ8+s35aEviwEmFDY6YYJWQIxelgAtRM7T0qTbZ1TvdG+4PNy0k6l8V+12ZoGR0Lg6TtXw2FkvlLuHLfSU= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8F0303860002 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=TM4CcErw DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752860616; x=1784396616; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=bzUa3QiT/s07stUG4qTVIJAqfOBc12CHNg7HB5paDSg=; b=TM4CcErwVl9V053sBqy/etL/aUSNpNYpVpDV6zV6SFdNKyk7Adtza3MP CDen7fve8EQl1ufl/nVPit0IB5CDu1clPq4IIm2ANHHpogCvIVjSKOEGj XUZxq2x8a5emHIeuUtNT+7FIsRZowBf4A7hOfkS8DXNWx2oclNQgPeepc 6rv9tsU3dKWyzsldpY57L8GrMXvLzbI0rqjkp3eYhdKK9pdVu7HATEFmO bDyES0Lgoyi+b52bjSB8M806Cei/w1gG1KkAWUZ/IV6YflugUw3Mv5pOz VfGg3si+5SVhW0gBkjRGvBMk/ZKQsgv0bum/LzQf0K0kpVR4f+7Vp2W0A g==; X-CSE-ConnectionGUID: JVw6p6s2Tlafqm1DfiAyHQ== X-CSE-MsgGUID: wSr9IxVVQ9+Xkjds64SsFg== X-IronPort-AV: E=McAfee;i="6800,10657,11496"; a="55248318" X-IronPort-AV: E=Sophos;i="6.16,322,1744095600"; d="scan'208";a="55248318" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2025 10:43:32 -0700 X-CSE-ConnectionGUID: HVR9pH05TcmZKqrFPwP4lw== X-CSE-MsgGUID: jg86ydtvQ5yb5bdjbV8K2Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,322,1744095600"; d="scan'208";a="158192005" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by orviesa007.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2025 10:43:31 -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.1748.26; Fri, 18 Jul 2025 10:43:30 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) 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.1748.26 via Frontend Transport; Fri, 18 Jul 2025 10:43:30 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (40.107.94.77) by edgegateway.intel.com (134.134.137.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Fri, 18 Jul 2025 10:43:30 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qjoJqqwkHWyatDpnCnCifSmAtxx0vMpv/k+HvVJhic0xyL/clrl05rjfpdtFgCWfoPGJOJTWNt9cucJwsz/cMlM/L5KyfK347IldAtI2bQhnQzZbYOrE44sHho/wCFKSro1hYVnEip0EGbWVDR1XjMLOqK/psXXpkoKDrcNyyVz3JABaZzC5emEP19UEfqDO3uPNWqeexYL7qaR/1jheA6xaTmlBecDoIt4NT3tzt4mW21M7OJbfgYgapuD3rZp5V+mW9BXJyhFhPogYlaPvPhLTEeXnPqsuY/339qjwS1gQ8usVwlzP2pX0QhCWuZ9YfUliaA+83yZx1YKQA/HURw== 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=ofYmeRHDRNVip7gDUHTTlhsayty+B66ONEpTdUsmVPw=; b=J2DnH/yFlbegbaQbjCB32udLLPm/G6r41Qla8ZTtI69Q3UWTAiDwCX3m8xY41MpOCezm408sgZg270bwp5cxo/6kUjDKf9GtMUTAq5xXcQ4rFx8/55yVUvnjR7H8ufp/om5hB7yqW3daCJ0BdYqjn2XTHlUZco2pu8NqzXeBfCcXfvk7xiaj6hHez+nNddxELRVtIYvCJLv1UEkFvYeNqEArVbyedKpHmGtu0skY5IhVK/kLvA8Q98zO/N18cmb+mkbtrhBOrozah6wPXoummit/iVg9KLoTK1NoFhtAmLMlhUItS2GJolEjEGQIsDnmNRbpqAydlx2D6a6kTwP/TA== 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 LV3PR11MB8727.namprd11.prod.outlook.com (2603:10b6:408:20d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8943.27; Fri, 18 Jul 2025 17:43:28 +0000 Received: from DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::3935:4973:1b78:da44]) by DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::3935:4973:1b78:da44%3]) with mapi id 15.20.8922.037; Fri, 18 Jul 2025 17:43:28 +0000 From: "Aktemur, Tankut Baris" To: Thiago Jung Bauermann , "gdb-patches@sourceware.org" CC: "Metzger, Markus T" Subject: RE: [PATCH v2 06/47] gdb, intelgt: add the target-dependent definitions for the Intel GT architecture Thread-Topic: [PATCH v2 06/47] gdb, intelgt: add the target-dependent definitions for the Intel GT architecture Thread-Index: AQHbTXhTrhiWoUpOxUW9kf1nZhnb1rQoyVBrgBBm5RA= Date: Fri, 18 Jul 2025 17:43:28 +0000 Message-ID: References: <20241213-upstream-intelgt-mvp-v2-0-5c4caeb7b33d@intel.com> <20241213-upstream-intelgt-mvp-v2-6-5c4caeb7b33d@intel.com> <871pqrtnao.fsf@linaro.org> In-Reply-To: <871pqrtnao.fsf@linaro.org> 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_|LV3PR11MB8727:EE_ x-ms-office365-filtering-correlation-id: d2c5cc9b-073e-4e85-ec46-08ddc6229ac2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|376014|1800799024|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?lE7h1/+P6bvGoqVwWBq8gcwdSHf+SqdFMqr2ZR5oRZzVm97gpjKuN0MlwnzB?= =?us-ascii?Q?JTRvOJ0G9HtWxQ3N4HjBXherfQeSDw0tBCOoZFhp0AhCiMQRdn63onkK9XHI?= =?us-ascii?Q?DNzOToPqM44UukuRao2t9v0yiANOM8OThn56W+qNheGmrZ417RhUcZgxNpG1?= =?us-ascii?Q?KCttMsBOQwCCMrzVcFyP6FvFD3WLy2nlHNRfvtFYhEuaKI6+7V03932JV2ul?= =?us-ascii?Q?lzkZdYt9oo0HuN3ZxYRTICLM1LpTav222kEmfjughGAQRfeyC42BTzE7zvGm?= =?us-ascii?Q?LHuG87Ab5DMYETtltAB2Z44C9L1sf9ePNJhoJfdIrheeXYa4GiVfUUflGQDU?= =?us-ascii?Q?xr8WyFeU+KAFhv8t/+acgE4o8wx2qpRHsREZJe6aH3CCQpx7jJh/YPw4PuSA?= =?us-ascii?Q?9F/By98meZX8Id/Z0h3FKaAPmUB0Wbv1GIRhhjmkxu3Yp/+rbtzw/GfjPuId?= =?us-ascii?Q?my29a8o9Qkw+R8yzRpt0H7Sa6RYCOGNrK3yOBiQo+mHlhFTVsMz6fqVrgTij?= =?us-ascii?Q?9UBqEpJPcCfXR+QRwrr03gxKdbtMuv1K7JfQlPJQnSHsLibDspfXsIQU46HA?= =?us-ascii?Q?GZfWXd7uEIgzX4y5fs0Xq+tSFOnT+6m9jHc+PrnFJmnLaUkcxYHl4hGbnP/v?= =?us-ascii?Q?V4CkKVfyUfiijUSixYtSyMNQ3SXqr/ZaO6FvE9Az776X5v3qeLwrSP+6syPW?= =?us-ascii?Q?V9M6uQ3N4FecnRj8GrM3tb6J9oAm0sgQMb2WvDidTjM0EODt+mHkHUtMvSuy?= =?us-ascii?Q?vCq2CksJ7AEfX5XBQxLOJUv2x1JTEs/iQcG1f5gy8raveh22pSIGOsfI/LxL?= =?us-ascii?Q?jORTibDPAl7mokSNJgwd7Qav87ue2Ms18vOZD6jptIXbs6ucrN/XrKWHbuNG?= =?us-ascii?Q?laoRvtHY7L9hMs4zkHf0Cd0d0Y2/IYZMr1pgmEhC09Eh7hsCSnxTDYqF54Rd?= =?us-ascii?Q?8l0lnajXXi7DhfYwJqgpR6bjePUmPkg8z2RUpFyit5bUsHLbWO0rw8oWEOSq?= =?us-ascii?Q?fV7xHfAwEhKoDnyTH+ohqzxYTQSBLzooSVaMRigKie5zygea9S8tC6147Phz?= =?us-ascii?Q?SC1I97maT0Hi4YIn9baiuwQnogo2vTTr5d96K5WLdEWrdrVD4YKDk+rSOF1I?= =?us-ascii?Q?k+Vp2PYm9IoSEdYTOk5jdSdEMcv5AXdxFqWDLui2xtToZ5dfm0eiQhOCJB78?= =?us-ascii?Q?75pJAHowne8bFl7BO2J6hLJokHoZKeOzf3fxPBnDkAI7PuHEd1/BI6o5ZQwJ?= =?us-ascii?Q?ycfAHQA8ApSIKUTXPwQnuqOsvu+glSSaIdtShycyJJP89j21swUnjC4O9PCi?= =?us-ascii?Q?y+jH7xncUfInW47q8dRgb/2NngXnTYhoKG1KryWhXu6XywgaQUcWm8dxU8X3?= =?us-ascii?Q?CnsREX6nxO+vaTNMTL340kQzxMBcgxa9oqA/CJTrcDBT2Jj24NuAtZb1UiIS?= =?us-ascii?Q?LGR9OtiLVYvICkgH2/udm0IVZ+s1Mtwxwdi1r9+a3TAd6QPXond7LA=3D=3D?= 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:(13230040)(366016)(376014)(1800799024)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2X8GSCtq5E2ya0J+/d6B3rg/Zm9doFWUAfWhamaf7JtEaaWJj4P/evZMEeG5?= =?us-ascii?Q?byS6q+BC+QyD3RWC7yJJ62cl3ibUvm4P6H3oceIgm34KeJ5cJA+33w+hlJJz?= =?us-ascii?Q?LCmqgQoJ5xvCZTqJlTl634hDcPi2zZ91a4q8xLtBNED452deZ8cQmliD87E3?= =?us-ascii?Q?GYa5WaEwUdubWa7MH6PJOj9CTezKWw4Mm8hI3V3tgFU9f2fGCT17BBm/xCG6?= =?us-ascii?Q?893woHxHVX6MiwcaulLUcJmSd03Fg8s7gd8uTuaoBDEivZzsjL74Ns6qP+3q?= =?us-ascii?Q?9eJyLIvarNhjZhTme8cVoGEKUXgY8ntBG5B/8ep/21CeEHCxBOwqhV99bFVu?= =?us-ascii?Q?SqO0l3Z1oaLiSck2TF/QnSInPAszkHygYp3wtba9rFZg2TTtFn1N3nPq/tSf?= =?us-ascii?Q?qqoEnuWMAS4XMaK6s2V7rtaLCNV1NSKGtmJE0tpoQ5c0aVamDDfhKkyb6vco?= =?us-ascii?Q?JZhDT/TzFpnQ/u6F3qgiLwuJq3vmGpo7tzC1cazz0ofpuapRV4Er3gVNb/VV?= =?us-ascii?Q?au6Pmt96L/GI7sFmO4mFsPlmevr4LpB4Hfx5N9s5Vsed0wfBXHMxutNaZE1y?= =?us-ascii?Q?Dm/KOHkJsoScL8AYW0vn6PqE74awZU+fvE4wqdAFR58VcYilM/3u/nQrjoUv?= =?us-ascii?Q?3hOGCWo92F5agGHz2U59MDxlHP1qAc0pMosUioHmlWBhEcpCMalOrwEDZGH3?= =?us-ascii?Q?EgVhqQz6NZhOFqC0iINKiDGJ1ZJh+ElpXC+PnfS7JPjY1o0XFbAwoZkZY3m/?= =?us-ascii?Q?UMqlY7NVehk0E59w/K6GBUGVPRZpFSUg7QLQ8dwo1fTUmhpg8TEe8TLEDibN?= =?us-ascii?Q?kBmnJBr6P5qZdLKvWWPW7qPmmICIKjJyjKAl8WPy/EhhAsdc2nEBbxbLH2hj?= =?us-ascii?Q?6i2nEdJZod4LvakjrrfR/MA/SE0zc0NJix1l7rUpJV5l+PX9cPlvHzxsdw6Q?= =?us-ascii?Q?GqK9GF1CcM9FixBft2SujG6BciiAyN2/4MBk3UETqzjWdWksCv701dEk0IHJ?= =?us-ascii?Q?cDVFoW9Nc5LIpea+hwko0ulpdnu/CEMwPxufYJm5Ho2m57vlRvqY9/hDJ7i9?= =?us-ascii?Q?beTazll1J9bvwJKELBbX6aPYTjG3lEYMuciD+r4OgugODVCXw3V0PjhnpbIy?= =?us-ascii?Q?r/0wG2Y0cLusGZ1TpiljV/JBJK80kIoltaIJdRnZ4CtLkR0xs/J6aNgnQaMm?= =?us-ascii?Q?jXQjFhhmH22QB13kmfk5CASuNY39wn7QXuazflA9f5wnUwMPVdC4rCrGpEFg?= =?us-ascii?Q?Y47fklutJQD9OHoJCgvs74KzK+Gy9eSFkf+KtOJh9FdloHr+DiuTo8qie+EK?= =?us-ascii?Q?ny1x8UcnAz4MN8KBheoL2p3PWpXxV0iA0kIH7nTUJTGB78uGBV+riSFbM9kD?= =?us-ascii?Q?3O2fHb195h0STPqZl67EaW/c9aooeGhqo1jugVUNyu9c9Da4Itg+E1u9HqDe?= =?us-ascii?Q?L46fsS/GoO6nmB/jRgVPe0FltyJMifHXx01+YiQW6cc3lWDALbIGTOVkz5tL?= =?us-ascii?Q?pZ0ZHAlXXP/Muwr2wSknY9ybBhibzYIhzaHt8raGwiB0iZqqLFFDxPS2E2cW?= =?us-ascii?Q?VGZbhfw0gZs65tWaArEjhXQVKQRLSPLXoio5brzdvE4csUF6spMQfZFyegBV?= =?us-ascii?Q?3Q=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: d2c5cc9b-073e-4e85-ec46-08ddc6229ac2 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2025 17:43:28.3903 (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: Wg7zqzRfaBwtVtndfDNHFiJlcYlLdPMeJdrppCH7eO5+INv/1fyp5Qy04mMUxDhJbCH8uF14va6+1eiSE8EWmYAizIQP7GUN9JPRsw4r7UY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR11MB8727 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable 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 Hi Thiago, On Tuesday, July 8, 2025 4:43 AM, Thiago Jung Bauermann wrote: > Hello Baris, > = > Reviewing this patch series has been on my todo list for a long > time. I'll try to go through it this week. Much appreciated. Thank you. Below I respond to a number of comments. For all the other comments, I upd= ated the code locally and will include the change in the next version. > > diff --git a/gdb/intelgt-tdep.c b/gdb/intelgt-tdep.c > > new file mode 100755 > > index 0000000000000000000000000000000000000000..57c359bf355c5771db38b8d= 213f6681a043c2b33 > > --- /dev/null > > +++ b/gdb/intelgt-tdep.c > > @@ -0,0 +1,980 @@ > > +/* Target-dependent code for the Intel(R) Graphics Technology architec= ture. > > + > > + Copyright (C) 2019-2024 Free Software Foundation, Inc. > = > Does the copyright on this file really start on 2019? Yes, 2019 is correct. > > + > > +/* Helper functions to request and translate the device id/version. */ > > + > > +[[maybe_unused]] static xe_version get_xe_version (unsigned int device= _id); > = > If the definition of get_xe_version is guarded by "#ifdef > HAVE_LIBIGA64", then this prototype isn't needed. > = > Also, the definition of get_xe_version can be moved to patch 8 ("gdb, > intelgt: add disassemble feature for the Intel GT architecture."), which > uses it. We moved the definition to arch/intelgt.h and .c. There are/will be uses in gdbserver/intelgt-ze-low.cc, too, in the next version after some refactorin= g. > > +/* The 'unwind_pc' gdbarch method. */ > > + > > +static CORE_ADDR > > +intelgt_unwind_pc (gdbarch *gdbarch, const frame_info_ptr &next_frame) > > +{ > > + /* Use ip register here, as IGC uses 32bit values (pc is 64bit). */ > > + int ip_regnum =3D intelgt_pseudo_register_num (gdbarch, "ip"); > > + CORE_ADDR prev_ip =3D frame_unwind_register_unsigned (next_frame, > > + ip_regnum); > = > There's no need to break the line above. Everything fits in one line. It goes until column 77, which was beyond the soft limit. Hence it was bro= ken. Similarly, for some intelgt_gdbarch_tdep *data =3D gdbarch_tdep (gdbarch); cases for which you commented, the line goes up to column 76 if not broken. I kept them as is. For others, I removed the line break. (This does not mean, however, that the file always follows the soft-limit r= ule.) > > +/* Frame unwinding. */ > > + > > +static void > > +intelgt_frame_this_id (const frame_info_ptr &this_frame, > > + void **this_prologue_cache, frame_id *this_id) > > +{ > > + /* FIXME: Assembly-level unwinding for intelgt is not available at > > + the moment. Stop at the first frame. */ > > + *this_id =3D outer_frame_id; > > +} > > + > > +static const struct frame_unwind intelgt_unwinder =3D > > + { > > + "intelgt prologue", > > + NORMAL_FRAME, /* type */ > > + default_frame_unwind_stop_reason, /* stop_reason */ > > + intelgt_frame_this_id, /* this_id */ > > + nullptr, /* prev_register */ > > + nullptr, /* unwind_data */ > > + default_frame_sniffer, /* sniffer */ > > + nullptr, /* dealloc_cache */ > > + }; > = > This unwinder doesn't do much. Is it necessary? If so, I suggest a > comment explaining why. Without this, if a program that has no debug info is debugged, GDB crashes = with Recursive internal problem. This unwinder avoids that problem. I'll add a comment. > > +static int > > +intelgt_memory_remove_breakpoint (gdbarch *gdbarch, struct bp_target_i= nfo *bp) > > +{ > > + intelgt_debug_printf ("req ip: %s, placed ip: %s", > > + paddress (gdbarch, bp->reqstd_address), > > + paddress (gdbarch, bp->placed_address)); > > + > > + /* Warn if we're inserting a permanent breakpoint. */ > > + if (intelgt::has_breakpoint (bp->shadow_contents)) > > + warning (_("Re-inserting permanent breakpoint at %s."), > > + paddress (gdbarch, bp->placed_address)); > > + > > + /* See comment in mem-break.c on write_inferior_memory. */ > = > I wasn't able to find that comment. Has it been removed from GDB? Seems like so. I removed the dangling reference to the comment. > > + return data->enabled_pseudo_regs[regnum - base_num].c_str (); > > +} > > + > > +/* Return the GDB type object for the "standard" data type of data in > > + pseudo-register REGNUM. */ > > + > > +static type * > > +intelgt_pseudo_register_type (gdbarch *arch, int regnum) > > +{ > > + const char *name =3D intelgt_pseudo_register_name (arch, regnum); > > + const struct builtin_type *bt =3D builtin_type (arch); > > + intelgt_gdbarch_tdep *data > > + =3D gdbarch_tdep (arch); > > + > > + if (strcmp (name, "framedesc") =3D=3D 0) > > + { > > + if (data->framedesc_type !=3D nullptr) > > + return data->framedesc_type; > > + type *frame =3D arch_composite_type (arch, "frame_desc", TYPE_CO= DE_STRUCT); > > + append_composite_type_field (frame, "return_ip", bt->builtin_uin= t32); > = > Isn't it better to use a function pointer type? This is what x86_64 and > aarch64 do: > = > (gdb) ptype $pc > type =3D void (*)() > = > Though I see further below that pointer and address lengths in gdbarch > are set to 64 bits, so perhaps things aren't very straightforward in > this architecture... An "IP" is a 32b offset that has to be combined with a 64b base address to refer to an actual instruction. Hence, we preferred to use the plain 32b t= ype. = > > + append_composite_type_field (frame, "return_callmask", > > + bt->builtin_uint32); > > + append_composite_type_field (frame, "be_sp", bt->builtin_uint32); > > + append_composite_type_field (frame, "be_fp", bt->builtin_uint32); > > + append_composite_type_field (frame, "fe_fp", bt->builtin_uint64); > > + append_composite_type_field (frame, "fe_sp", bt->builtin_uint64); > = > If the 'p' in the fields above mean "pointer", would a void pointer > work? This is what x86_64 and aarch64 do: > = > (gdb) ptype $sp > type =3D void * The fe_sp and fe_fp fields are actual addresses. It makes sense to use a void pointer type for them. I updated their types. The be_ fields, however, are 32b values that are meaningful only in combination with other data. Let me not change them. > > + data->framedesc_type =3D frame; > > + return frame; > > + } > > + else if (strcmp (name, "ip") =3D=3D 0) > > + return bt->builtin_uint32; > = > Same note about using a function pointer type as in return_ip above. Yes, this is again a 32b value that, as is, does not really point to anythi= ng. After being combined with a base address, it becomes a "PC". > > + /* Unconditionally enabled pseudo-registers: */ > > + data->enabled_pseudo_regs.push_back ("ip"); > > + data->enabled_pseudo_regs.push_back ("framedesc"); > > + > > + set_gdbarch_num_pseudo_regs (gdbarch, data->enabled_pseudo_regs.= size ()); > > + set_gdbarch_pseudo_register_read_value ( > > + gdbarch, intelgt_pseudo_register_read_value); > > + set_gdbarch_pseudo_register_write (gdbarch, > > + intelgt_pseudo_register_write); > > + set_tdesc_pseudo_register_type (gdbarch, intelgt_pseudo_register= _type); > > + set_tdesc_pseudo_register_name (gdbarch, intelgt_pseudo_register= _name); > > + set_gdbarch_read_pc (gdbarch, intelgt_read_pc); > > + set_gdbarch_write_pc (gdbarch, intelgt_write_pc); > > + } > > + > > + /* Populate gdbarch fields. */ > > + set_gdbarch_ptr_bit (gdbarch, 64); > > + set_gdbarch_addr_bit (gdbarch, 64); > = > I'm a bit surprised by these, considering that PC is 32 bits. If this is > correct, then it's worth adding an explanation about the discrepancy. > Is this why PC is uint32 instead of a pointer type? PC is still 64b. The hardware provides a 32b subregister (CR0.2, to be pre= cise) which is added to a base address called "isabase", to obtain the PC. The 32b value in CR0.2 is provided as a pseudo register named "ip" for conv= enience. intelgt_read_pc and intelgt_write_pc functions compose and decompose PC thi= s way. Do you think such a comment should be written here? = > > +/* Dump the target specific data for this architecture. */ > > + > > +static void > > +intelgt_dump_tdep (gdbarch *gdbarch, ui_file *file) > > +{ > > + /* Implement target-specific print output if and > > + when gdbarch_tdep is defined for this architecture. */ > = > From looking at gdbarch_dump in gdb/gdbarch-gen.c, you can just pass > nullptr to gdbarch_register instead of having to define a dummy function. > = > Though the comment isn't accurate. There is intelgt_gdbarch_tdep, but > perhaps it's not necessary to dump any of its values? As far as I remember, it used to be required to pass a non-null function po= inter. It doesn't seem to be case anymore. Thanks for noting this. Removing the intelgt_dump_tdep function. > > +void _initialize_intelgt_tdep (); > > +void > > +_initialize_intelgt_tdep () > = > Update to current style using INIT_GDB_FILE macro. I couldn't follow. Could you please clarify or point to an example? -Baris Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928