From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id rUSiK3VurWh0lwwAWB0awg (envelope-from ) for ; Tue, 26 Aug 2025 04:21:09 -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=R5ZPfyZz; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9F7ED1E043; Tue, 26 Aug 2025 04:21:09 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no 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 140951E043 for ; Tue, 26 Aug 2025 04:21:05 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 948F1385C6C8 for ; Tue, 26 Aug 2025 08:21:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 948F1385C6C8 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=R5ZPfyZz Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by sourceware.org (Postfix) with ESMTPS id 555BC3858CD9; Tue, 26 Aug 2025 08:19:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 555BC3858CD9 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 555BC3858CD9 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=198.175.65.19 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1756196393; cv=fail; b=NfkF3dZE2HvjZKs/rq2VsHv/NZA7RqG8VgkN1fG1WRvJLAXjHiaKXvDPhb/gUXO2ejPa4XfuO9XwtGtsaouopUzVXg9HDd0Xwf7dLeafCp7rZXaQsjPBGKt/9qe4E0rYtrME4UamXvpSP5/NVa2erSnu3NJDBn6wXk41Fm/N0fk= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1756196393; c=relaxed/simple; bh=Lbyz53g/d3xfwjo5YMEPpugTQumVgyOt1wc1R0lchyc=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=GswZ9xOYd0QuwRvLAkf+J6GruI55lG7V+AhO0HZsSL3FOY3T9FabFnJCadyaAVHWfWuzy8MSC+Q7aIxDSVPyjZkDUIDnh/+2gj8aqhhPiPWqvS4n6QKWE45T91Q/LCDSxb96Tvk9FgcKZMAIOs0Q+6iib6U6AN8zxEHvu2kcmwk= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 555BC3858CD9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1756196393; x=1787732393; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=Lbyz53g/d3xfwjo5YMEPpugTQumVgyOt1wc1R0lchyc=; b=R5ZPfyZzasSUsa2CIemMVL/SupXp5OJ1zWE4O1v58UMn7CBjO0MRj+U2 S83sKpS46G36dkcttizVMqTtQJwpnFdRwgK1LaL0MemJfJJY6il0tgHGh JPEzNLrDAIywj4f37xJn/eYb1XSEc+zRoOo03fQueJ7oUuVpXKPXcQJMf qyjMK9NHdwLx109oA8aYZ7dvCo/+AvhHBnNMR9z7oQyjNvjvHIZStrxrV nVuat4KRS7l5XRGAfdkcIeq3AQIcsWjbcQ+ZngVwjcohX3pQAMlsTum10 yyWE+yFnw8iSq06M2Mv1kSJNmhfjJnEb1BHK3/rGGoG2gov7nAuROacHK A==; X-CSE-ConnectionGUID: zaEeTcb9QDK4xOFZhpL+mQ== X-CSE-MsgGUID: ZpMCAv4sQwWXjJA9DtDc8g== X-IronPort-AV: E=McAfee;i="6800,10657,11533"; a="58281672" X-IronPort-AV: E=Sophos;i="6.18,214,1751266800"; d="scan'208";a="58281672" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2025 01:19:51 -0700 X-CSE-ConnectionGUID: qPbN1rtHSnieNGx3DzPZoA== X-CSE-MsgGUID: RGYqa+mbT9mjzQhvM06U5A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,214,1751266800"; d="scan'208";a="169914166" Received: from fmsmsx901.amr.corp.intel.com ([10.18.126.90]) by fmviesa009.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2025 01:19:50 -0700 Received: from FMSMSX901.amr.corp.intel.com (10.18.126.90) by fmsmsx901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 26 Aug 2025 01:19:50 -0700 Received: from fmsedg903.ED.cps.intel.com (10.1.192.145) by FMSMSX901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17 via Frontend Transport; Tue, 26 Aug 2025 01:19:50 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (40.107.237.57) by edgegateway.intel.com (192.55.55.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 26 Aug 2025 01:19:50 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pDRkf0Tn4cjmsK3ZfBZ3X2BULUJy9w3qyyttlCahI+sRNkZT3yBcsniYkq8QpI+ij8H9qzM85YR1/aQZkFglQgoWavUQQvJiaQoD+DJyHn1eqzqmc1imA3c0jiG0lO26LC4LU1oZomjhlxAYDaEVxDuY58klMtjarOEYpIfIvBf06fjIv5Y/y+VQ0E/uevpIukjA2GIxG/kchevyUuqxert5r01mvyioJu063HXTRA9qY9lk40fa7wLCFM4jLMjBOh3tjwI+NpO62dqyMZn0U+rO1BJ4v0i/Ut2wroYiNjQQz2kqof6LQ70ICeh6g/kSBUAUl4dRWoGuUyu1tlYdwQ== 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=tpqAr6nBI+ywyjUtxWQ4vUPmOBZ6Aunclkx7MueaKZk=; b=Aj2E+rBfA3awHyHov79xmIjH9iH47FDrvz+Hi9GrlxoSNcREkKQwPs7cN+ChUEr6YNegYUMREomBtLgSbK3LzLYov6xFj7fDnsrFhI0yGSMPnCKqKGiuxuzSqvMqqnpCnEsQH6h5qm9nYbMKhbQytcgL8hi9PDCtYkO0wRf+0EHPVctVXrq3VmVzUCu3LDgmDu9wKuvopz5ePPDwZOSgreZxCYdaJboPs9L+wPHgw/YXhRike3hTvUMO4DEDDUc8jcwiLpIOMNPukOs/lWFhMtkLYRiivPGXCKro54Liatjo6fUlbb77bAfsZK/y8ZbDDTxhiQ6oDNHjJovjp47uXA== 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 DM3PPFD7E67F036.namprd11.prod.outlook.com (2603:10b6:f:fc00::f54) by SJ5PPF183C9380E.namprd11.prod.outlook.com (2603:10b6:a0f:fc02::815) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9052.21; Tue, 26 Aug 2025 08:19:46 +0000 Received: from DM3PPFD7E67F036.namprd11.prod.outlook.com ([fe80::e0d0:8d5a:e8dd:5316]) by DM3PPFD7E67F036.namprd11.prod.outlook.com ([fe80::e0d0:8d5a:e8dd:5316%3]) with mapi id 15.20.9052.014; Tue, 26 Aug 2025 08:19:46 +0000 From: "Gerlicher, Klaus" To: Sam James , "Beulich, Jan" , "Tom de Vries" CC: "Jiang, Haochen" , Binutils , "gdb-patches@sourceware.org" , H.J.Lu , Alexander Monakov Subject: RE: Inconsistent usage on onebyte_modrm and twobyte_modrm table in x86 disassembler and gdb? Thread-Topic: Inconsistent usage on onebyte_modrm and twobyte_modrm table in x86 disassembler and gdb? Thread-Index: AQHcFao29uqICtzA+U6hEMSPPK7qnbR0lwiQ Date: Tue, 26 Aug 2025 08:19:46 +0000 Message-ID: References: <92aea037-9c0e-438f-8a0a-fd52dd2df7bc@suse.com> <87v7mbrdqn.fsf@gentoo.org> In-Reply-To: <87v7mbrdqn.fsf@gentoo.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: DM3PPFD7E67F036:EE_|SJ5PPF183C9380E:EE_ x-ms-office365-filtering-correlation-id: c4593300-9cfe-49df-1816-08dde4795174 x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|1800799024|376014|366016|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?+8ud3ZHeWrV/44GURHiUDefLcfvGObPfnkfJCV+Oqm31E/R/XmQhrv4C3QY2?= =?us-ascii?Q?nx+RDKiQDqS/4T0rj0yJCC468RyZp7TtmBZ0/hYufnbCGSesSU7qbMupUG8+?= =?us-ascii?Q?WfIExq6Ha2G/4Y4sHjRCBywCjvqkEP6a01w7N5kGt53sDEhl5m8p/6GWAa7q?= =?us-ascii?Q?vyUdVdvQDmWeDWzQLHYGqbw+o0HBHq7x1DcHmIM5IxM/s48kIPSdOSD8LEXQ?= =?us-ascii?Q?OIl0DuzVO8A8wWh6il6XY7h//Mh/yZZwd3sr+5jAKTp9Chn5iRHoMALZnL4y?= =?us-ascii?Q?qjCdAz3NUtwrvVFz022JHudh3QqZZVKHF0SGNR5ks/zmZ3S1STyVDxWb4tAY?= =?us-ascii?Q?+iO+9H5NrgsxM7by2omP3HfLQwXLHTXa73sHfEyCVrtmFPPG1TkgdoBQibQx?= =?us-ascii?Q?NhiigY7C4cgbSqdmwr86E8vEk1l2WfrsIsk39dujL/3shnuabqRCDnHPlK2B?= =?us-ascii?Q?AJ4k/zgMmXcqd6Ds4pS/SWqu9ri2EQvv5dsNshGs3XynmmtILnpEOiz5Hamh?= =?us-ascii?Q?ix5glVB9Q/NzZJHkfyJCwZX9cdJfJxcNs9PjhHiZWsgBriMDEH6a4GqOhKc8?= =?us-ascii?Q?jXhQfmAL3R8hXfTlEGXp7RDNkKJhzsFF8dZuYiSBAzQS/iVjM7l92Z+6ro82?= =?us-ascii?Q?QqCxgvSWLatIiL8oWxSeeNsKrE1y4gUOGdXBYOmFnriI0+6ZDpXZbUnliRfr?= =?us-ascii?Q?2NeUqOdxYPdf9tG5Dt/YVXZ6NrerBiyzh17MWGVTJZ3fbfx94uO4NSx1hJLp?= =?us-ascii?Q?BJrVh9uhbtuC1t56vBFoJXg1dm9JkLKYK5AFPOT+QCsvPqG44he4+Trh8gA4?= =?us-ascii?Q?+R3tM0wdVqdBfz2wR27JOorQqY2esC4wgVcQAGk8AcgTrGj2NgRTR7aAPO6l?= =?us-ascii?Q?jxhmtKdKn+xNcHfDQ6VUYgdyajbqAP6hTWjv4jAP2gnBG4gZFLBqcQMp7UTy?= =?us-ascii?Q?2TH6bJ9/ZwSwqYh+ODIOurzUo6U9v8M1mR02+p4ysR0KvhLbg3XT0ucm7/Vk?= =?us-ascii?Q?UeeYYf9RJ6HzXxCGYOMuwUaALBTS8oLb06DZWQubGPI1kIkys7dsqM0RWGII?= =?us-ascii?Q?QW/DAUXUbQNHpk2sJ69/Zw9c9mfvL1SxQdxABOJpWPKM5oCotctxtpDQrlGe?= =?us-ascii?Q?xbWYIHBT4c6o5pWxBjpkdrZp+gXgiynIr2/dHb4LkQK5OEuxqCVCOvuiHavJ?= =?us-ascii?Q?+b/TeLnA+6myGoMSKtpzTm+K+70mzQpiOGMFsgN7EeLFLLSO671FuZH4aWdi?= =?us-ascii?Q?zy371ZhmOIwEk1V6Tp5hsnFtUUEoGmq4aF2z5Jzu3rlv07C8RMSnXP9fOj4t?= =?us-ascii?Q?5rWg7usyrfPlk/hNWBP09KiUZ1MaDGu30AhB7QwaSREQUEDmv1H32jRiYuVR?= =?us-ascii?Q?XoSGeZQbuPLTnoEscX3YKywnyqwrRW/4+nkfbYzz0LEgq5RNOq8vDVoYv83n?= =?us-ascii?Q?k205A50kZxY=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM3PPFD7E67F036.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(376014)(366016)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GN4xP5jI21FPXsO0klXzY0BSWtoH1FiSZoxzDessN/zPl04vN8xLXrLF96XS?= =?us-ascii?Q?Y1nhJHuT8NyJGlNSCT8WYgbYmekbok9qWCCw/W2P+vGhSjdAQvp36gD/YNTg?= =?us-ascii?Q?6dJF7/tgGzg5bT6HFOKnmjwjYbKV4MhsF2aRZp/Y6x5XOM/is078nqC+ZWUV?= =?us-ascii?Q?64vRSZDS1Y83bLd+WOfNwjixIbuSRNYgN8EWDYu8urKoQBvSh8PslPFaV6MH?= =?us-ascii?Q?95eHpYhoDa3myHC8xMd5+UAesiexF22Q3fo+lCw4DqoLya25auXVt9snpRiQ?= =?us-ascii?Q?y2cOsxbmeV63WeMxrpSA+xctIkEKquvBziHndEaKvDGwQPRWxroyHRsIM3tI?= =?us-ascii?Q?KpzkXv5QSrVwmbO5yiBY0mFHfTzmKjqazaRWK/C5CU2rQ4bJfabYYB9KMeqg?= =?us-ascii?Q?o6Bv9Op9D1+b6mhEXZY5zTd2z6LWYWY4htFP9nHXu8bh//zbswUeJwMUZMrX?= =?us-ascii?Q?ZR2OIOP6ExGldoeW87GzTJUJS5sEALKHNMnFD+s7jdxZn8J/wBKBqJJnZAnB?= =?us-ascii?Q?TF1j58LCGcRIIN78eo2yT9Qd9KTdzKV9E88iMOafcrsCBZEXKCM9yoozeUyh?= =?us-ascii?Q?M2bYbVxhOVvTroh77UXeCizKqleMTB4LffeuzcLQj7UqnU3AYf1fcnsQWfI6?= =?us-ascii?Q?6RrwgzWQ0g7cjqLAioP9pmW+IThwrCCGO56SGkIVw32IG7TBY0v32gq7zulD?= =?us-ascii?Q?8We1oJB0cs5a2LcbC11FcYONG//kHLNeCHECLsC48YfYVkgFg5Os1AUHZ2+2?= =?us-ascii?Q?877++hDOlNiLrUaXAnVkbSp/5pLi43oycuEuMJkc0sYr8DRvzp/24g0L+N4Q?= =?us-ascii?Q?/bm7tYSCOr/kIlQC69yC5LFRxLm4NRnMgE1GV1194/DC1zNZl9aSVKDT0LxR?= =?us-ascii?Q?JuL80C7ujkmeo577wS/sqd7w07eRRydeTGXWe8rjo2r8rFDByooF71GS2Tja?= =?us-ascii?Q?g1p+ag225niQg6lmYzdAxYXRBOFovffCgLE3nZR8WbYA2S3tpDb7F1FVCBZo?= =?us-ascii?Q?w97ndyONo5/Hg/gd8TfWTg2dTHTaTcvjYjhBg21X85O5lLlec9OPjg26i5Vo?= =?us-ascii?Q?8Oed+kK6I58+h2oQ+MLx44Wxo4fcsEm2iwy/aOy2hjAeTV8GICnXHFT847F0?= =?us-ascii?Q?UaR1vSPFdr9dbN5uh0CG5TYMElvqUTUf/ZsYJM5NOXIsl6WOcgjHKKLwoO38?= =?us-ascii?Q?vBRBbYpyt6oYnWVcdj86H5uVBs10xQ+IHN6+Uh7HjatzwR1xqBZM8ZnKkAEO?= =?us-ascii?Q?MsKz2SjxalZTCOmMhFapym+9LNxfDAP2/ktvPq/UDX6HQh8nOCzCfLybDmds?= =?us-ascii?Q?4DV4vyfwsFj285naGYdgkM3AuvgXFGHfImndwrjxYNgd1Jj/jYu6Yb5AzR0b?= =?us-ascii?Q?nFleH74iKprb+MxsNKBa7OsxxofQkKXAXm63vKQFL6/3woB4J99YFj5LBxCO?= =?us-ascii?Q?ujlTbQAnP51R6XmOsKO6Mph9u/BFlHucUJHhqZX3jOFAhHekgRjfd2FfsapR?= =?us-ascii?Q?ZJWpGBKiTvuiOmiCYpDcZZvxSl0tlvmTgLiQjGlsLzC8qJ9bhhN2S+6q2hTw?= =?us-ascii?Q?ByWPDuY9x8dUHRhvRoBwBWIMSubXOyMMyMRIqJdB?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM3PPFD7E67F036.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4593300-9cfe-49df-1816-08dde4795174 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2025 08:19:46.4415 (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: /URf1ZRWrchBmwQHoaApVkPtSSI0wdMGoQEpT94kbDYxNL3Q9Hlj7MyOQElDK6jBdc26zotDIefi4BCdCqAUkxxIljj/TMnI6PRcPnenJbg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF183C9380E 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 > -----Original Message----- > From: Sam James > Sent: Monday, August 25, 2025 10:46 AM > To: Beulich, Jan > Cc: Jiang, Haochen ; Binutils > ; gdb-patches@sourceware.org; H.J.Lu > ; Alexander Monakov > Subject: Re: Inconsistent usage on onebyte_modrm and twobyte_modrm > table in x86 disassembler and gdb? > = > Jan Beulich writes: > = > > On 25.08.2025 04:42, Jiang, Haochen wrote: > >> Hi all, > >> > >> Recently I happened to have a look at the gdb code. At gdb/amd64-tdep.c > >> L1102 comment, it mentioned that: > >> > >> /* WARNING: Keep onebyte_has_modrm, twobyte_has_modrm in sync > with > >> ../opcodes/i386-dis.c (until libopcodes exports them, or an alterna= tive, > >> at which point delete these in favor of libopcodes' versions). */ > >> > >> This means the table content and usage should be the same as gas. > >> > >> However, when we are using the table in disassembler at opcode/i386-di= s.c > >> L9877, it is: > >> > >> /* REX2.M in rex2 prefix represents map0 or map1. */ > >> if (ins.last_rex2_prefix < 0 ? *ins.codep =3D=3D 0x0f : (ins.rex2 & = REX2_M)) > >> { > >> if (!ins.rex2) > >> { > >> ins.codep++; > >> if (!fetch_code (info, ins.codep + 1)) > >> goto fetch_error_out; > >> } > >> > >> dp =3D &dis386_twobyte[*ins.codep]; > >> ins.need_modrm =3D twobyte_has_modrm[*ins.codep]; > >> } > >> else > >> { > >> dp =3D &dis386[*ins.codep]; > >> ins.need_modrm =3D onebyte_has_modrm[*ins.codep]; > >> } > >> > >> It will use the very first byte of the bytecode. > >> > >> On the other hand, in gdb, let's take VEX prefix as example at > >> gdb/amd64-tdep.c L1349, the logic is: > >> > >> /* Skip REX/VEX instruction encoding prefixes. */ > >> ... > >> else if (vex2_prefix_p (*insn)) > >> { > >> details->enc_prefix_offset =3D insn - start; > >> insn +=3D 2; > >> } > >> else if (vex3_prefix_p (*insn)) > >> { > >> details->enc_prefix_offset =3D insn - start; > >> insn +=3D 3; > >> } > >> ... > >> if (prefix !=3D nullptr && rex2_prefix_p (*prefix)) > >> { > >> ... > >> } > >> else if (prefix !=3D nullptr && vex2_prefix_p (*prefix)) > >> { > >> need_modrm =3D twobyte_has_modrm[*insn]; > >> details->opcode_len =3D 2; > >> } > >> else if (prefix !=3D nullptr && vex3_prefix_p (*prefix)) > >> { > >> need_modrm =3D twobyte_has_modrm[*insn]; > >> ... > >> } > >> ... > >> > >> It will skip the VEX prefix and use twobyte_has_modrm table instead of > >> onebyte_has_modrm[0xc4/c5] in disassembler. The table usage are totally > >> different although the table itself is the same. It will cause the nee= d_modrm > >> value different eventually. For example, opcode for VPBLENDW under 128 > bit > >> is "VEX.128.66.0F3A.WIG 0E /r ib". The need_modrm would be false in gdb > >> since twobyte_has_modrm[0x0e] is false. > >> > >> Does anyone know the reason on that? It is weird to me. > > > > Same here; see https://sourceware.org/pipermail/gdb-patches/2019- > February/155347.html. > > That patch might require re-basing and some work to be up-to-date again, > but > > fundamentally it still looks applicable. I don't really understand why = stuff > > like this isn't allowed in. Pedro's desire for a testcase is understand= able, > > but shouldn't block such a patch (there was a 2nd one s well) for this = many > > years. > = > I didn't realise a patch was rotting for this. There's Alexander's > PR28999 (and a few other either dupes or very-related bugs) too. > = > While I can understand wanting a testcase, tdep is really in a sorry > state for x86 anyway, and this clearly makes it better. Perhaps with > Haochen's interest, we can finally get it in. But I don't see any > specific x86 maintainers for gdb. > = > sam Hi all, FWIW I'll attach my fix for the (V)PBLENDW. It has a testcase and a unittes= t case. = I believe with this there are no other instructions that would not be handl= ed correctly. VEX and EVEX-encoded instructions generally require a ModR/M byte, with the notable exception of vzeroall and vzeroupper (opcode 0x77), which do not use ModR/M. This change sets need_modrm =3D 1 for VEX instructions, and adds an excepti= on for instructions where *insn =3D=3D 0x77, following Intel's SDM. EVEX has no exceptions and thus always sets need_modrm to 1. Additionally, the legacy twobyte_has_modrm table cannot be used for VEX and EVEX instructions, as these encodings have different requirements and exceptions. The logic is now explicit for VEX/EVEX handling. Add vpblendw to selftest amd64_insn_decode. Note there's no EVEX testcase added here even though decoding logic for EVEX has also changed. The Intel SDM says the following: 1. Intel(r) 64 and IA-32 Architectures Software Developer's Manual Section 2.2.1.2 - Instruction Prefixes "The VEX prefix is a multi-byte prefix that replaces several legacy prefi= xes and opcode bytes. The VEX prefix is not an opcode; it is a prefix that modifies the instruction that follows." Section 2.2.1.3 - Opcode Bytes "The opcode byte(s) follow any instruction prefixes (including VEX). The opcode specifies the operation to be performed." Section 2.2.2 - Instruction Format "If a VEX prefix is present, it is processed as a single prefix, and the opcode bytes follow immediately after the VEX prefix." Source: Intel(r) SDM Vol. 2A, Section 2.2.1.2 and 2.2.2 (See Vol. 2A, PDF pages 2-4, 2-5, and 2-7) 2. ModRM Byte Requirement Intel(r) SDM Vol. 2A, Table 2-2 - VEX Prefix Encoding "Most VEX-encoded instructions require a ModRM byte, except for a few instructions such as VZEROALL and VZEROUPPER." Source: Intel(r) SDM Vol. 2A, Table 2-2 (See Vol. 2A, PDF page 2-13) --- gdb/amd64-tdep.c | 24 ++++++++++++++----- gdb/testsuite/gdb.arch/amd64-disp-step-avx.S | 19 +++++++++++++++ .../gdb.arch/amd64-disp-step-avx.exp | 20 ++++++++++++++++ 3 files changed, 57 insertions(+), 6 deletions(-) diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c index 1adf81602b0..a273cb9594c 100755 --- a/gdb/amd64-tdep.c +++ b/gdb/amd64-tdep.c @@ -1686,13 +1686,12 @@ amd64_get_insn_details (gdb_byte *insn, struct amd6= 4_insn *details) } else if (prefix !=3D nullptr && vex2_prefix_p (*prefix)) { - need_modrm =3D twobyte_has_modrm[*insn]; + /* All VEX2 instructions need ModR/M, except vzeroupper/vzeroall. */ + need_modrm =3D *insn !=3D 0x77 ? 1 : 0; details->opcode_len =3D 2; } else if (prefix !=3D nullptr && vex3_prefix_p (*prefix)) { - need_modrm =3D twobyte_has_modrm[*insn]; - gdb_byte m =3D prefix[1] & 0x1f; if (m =3D=3D 0) { @@ -1701,12 +1700,16 @@ amd64_get_insn_details (gdb_byte *insn, struct amd6= 4_insn *details) } else if (m =3D=3D 1) { - /* Escape 0x0f. */ + /* Escape 0x0f. All VEX3 instructions in this map need ModR/M, + except vzeroupper/vzeroall. */ + need_modrm =3D *insn !=3D 0x77 ? 1 : 0; details->opcode_len =3D 2; } else if (m =3D=3D 2 || m =3D=3D 3) { - /* Escape 0x0f 0x38 or 0x0f 0x3a. */ + /* Escape 0x0f 0x38 or 0x0f 0x3a. All VEX3 instructions in + this map need ModR/M. */ + need_modrm =3D 1; details->opcode_len =3D 3; } else if (m =3D=3D 7) @@ -1722,7 +1725,8 @@ amd64_get_insn_details (gdb_byte *insn, struct amd64_= insn *details) } else if (prefix !=3D nullptr && evex_prefix_p (*prefix)) { - need_modrm =3D twobyte_has_modrm[*insn]; + /* All EVEX instructions need ModR/M. */ + need_modrm =3D 1; = gdb_byte m =3D prefix[1] & 0x7; if (m =3D=3D 1) @@ -4254,6 +4258,14 @@ test_amd64_get_insn_details (void) =3D { 0x62, 0xf1, 0x7c, 0x48, 0x28, 0x81, 0x00, 0xfc, 0xff, 0xff }; fixup_riprel (details, insn.data (), ECX_REG_NUM); SELF_CHECK (insn =3D=3D updated_insn); + + /* INSN: vpblendw -0x400(%rip),%zmm0, evex prefix. */ + insn =3D { 0xc4, 0xe3, 0x45, 0x0e, 0x25, 0x3a, 0x0f, 0x00, 0x00, 0xff }; + amd64_get_insn_details (insn.data (), &details); + SELF_CHECK (details.opcode_len =3D=3D 3); + SELF_CHECK (details.enc_prefix_offset =3D=3D 0); + SELF_CHECK (details.opcode_offset =3D=3D 3); + SELF_CHECK (details.modrm_offset =3D=3D 4); } = static void diff --git a/gdb/testsuite/gdb.arch/amd64-disp-step-avx.S b/gdb/testsuite/g= db.arch/amd64-disp-step-avx.S index 9b6b2b1f3ed..d83eb14f777 100644 --- a/gdb/testsuite/gdb.arch/amd64-disp-step-avx.S +++ b/gdb/testsuite/gdb.arch/amd64-disp-step-avx.S @@ -43,6 +43,18 @@ test_rip_vex3: test_rip_vex3_end: nop = + +/* Test a VEX3-encoded RIP-relative VBLENDW instruction. */ + vmovsd ro_var_vpblendw(%rip),%xmm0 + + .global test_rip_vex3_vblendw +test_rip_vex3_vblendw: + vpblendw $0x03, var128_vblendw(%rip), %ymm0, %ymm1 + .global test_rip_vex3_vblendw +test_rip_vex3_vblendw_end: + vmovdqu %xmm1, var128_vblendw(%rip) + nop + /* skip over test data */ jmp done = @@ -52,6 +64,10 @@ ro_var: .8byte 0x1122334455667788 .8byte 0x8877665544332211 = +ro_var_vpblendw: + .8byte 0x1122334455667788 + .8byte 0x8877665544332211 + /***********************************************/ = /* All done. */ @@ -67,4 +83,7 @@ done: var128: .8byte 0xaa55aa55aa55aa55 .8byte 0x55aa55aa55aa55aa +var128_vblendw: + .8byte 0xaa55aa55aa55aa55 + .8byte 0x55aa55aa55aa55aa .section .note.GNU-stack,"",@progbits diff --git a/gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp b/gdb/testsuite= /gdb.arch/amd64-disp-step-avx.exp index 4ae6461fb0d..4bd9f93d8fa 100644 --- a/gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp +++ b/gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp @@ -140,5 +140,25 @@ with_test_prefix "vex3" { "var128 has expected value after" } = +# Test a VEX3-encoded RIP-relative instruction that was falsely +# identified as not having a ModRM byte. +with_test_prefix "vex3_vblendw" { + # This case writes to the 'var128' variable. Confirm the + # variable's value is what we believe it is before the AVX + # instruction runs. + gdb_test "p /x (unsigned long long \[2\]) var128_vblendw" \ + " =3D \\{0xaa55aa55aa55aa55, 0x55aa55aa55aa55aa\\}" \ + "var128_vblendw has expected value before" + + # Run the AVX instruction. + disp_step_func "test_rip_vex3_vblendw" + + # Confirm the that the store of the vpblendw result changed + # ymm1 register + gdb_test "p /x \$xmm1.uint128" \ + " =3D 0x11223344aa55aa55" \ + "ymm1 has expected value after" +} + # Done, run program to exit. gdb_continue_to_end "amd64-disp-step-avx" -- Thanks Klaus 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