From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-DB5-obe.outbound.protection.outlook.com (mail-db5eur02on2061.outbound.protection.outlook.com [40.107.249.61]) by sourceware.org (Postfix) with ESMTPS id C15163858C54 for ; Thu, 19 Oct 2023 08:36:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C15163858C54 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C15163858C54 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.249.61 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697704572; cv=pass; b=XDdtA/zJeFQ+ISJFlBVQdlX6I0LTUtq0GkOuyBzOi1TOgJ9WZ3pZ1T1gr54TxmrOuts3w6dQTCXr6JVhEkT8aHxw907r4+FWF7aIF891EWIJDzZ2iPHVJ80LiZv2jahEDe/a+Nye/S362wFtBlCTFzYzSQ55TN0IX81ylET2QW8= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697704572; c=relaxed/simple; bh=fUPl/mqI/K6yQvH+BH1invtS7SElsFLU48+8+dphKQ4=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=thEawRFQ1c9a1pGMsxy2w1UTTYg9co1WWsHdPrujTs2qBnMxp5hsn5z8zAwY2b3r+ZcNb1FQOayNusT8hr9xpCNH9x3oVK5YpUIAnWp9Mn9IB70MhpLS8hIGZTcBg9DpSdRvZgS9U809AcOx8McH+I1oM6MQTQd3yXdFloHcVMM= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mbdqbO5LmS0SBD/SdLH69nrba+CXTc+eqVsTcKc+JKS0zQdpA+0sW/d2IcFOEExx9/YUx9AewOBezoa5cP2emsp3iuGwCTHIj+MWaBAMhUovwicdRmbhDKcsjdvbTXicp/FlT/tGRBNn+A/Z5u6xbLmlqsUYpaPG0PkLQd5KvzkckCsPoxNQISnZMvOPIOoOp0ENGVZWAOnhYTE5DfmD3C9CdxD4qEXYjpKrf62bMO6Ljjs7mqnb3dlyLawiY3+NA3ctM5JZPHhJLhW4hTvVPAW9IcXyo1A2dnYM4kRibaFRkyL2a45u+ZKterHH/2jf5N6Cr+t95KSxo/9FQRckvA== 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=+l3ffdFMECwI7JloXH93uMq1GyzUH4hQpxOOg/ZrefA=; b=ATN/16qX9e2zmmbWVA00p6g90Qs7LtwBop7oZ47JcGXj8Mp/UqgmXIuLI5lMmg2sx+tufhRgro11QwAJhbC4Z8XlLNKJKGB0kQGVBx+OS7Zz8Ho27t7ZWdiRYZcr0yXA54QHgTcArk1ovpCKb4qpShQgDVso9OZSivQ8shskhn89SsWR61GA87QAN/ORkDTRhL1tS30JTZzje1TJEc4GFZmPqZX6ir86Jb0J/5G8EzED7+SA5mtpa7uErX4K8R6bwNJorL3w/Y2aUaErI3UVrjVGOzf50kKfe8GNOKvEqpqaZtLjLQRzTkpa4JnPxkFG0nGPLQ/pGsVTv5Em5FjayQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+l3ffdFMECwI7JloXH93uMq1GyzUH4hQpxOOg/ZrefA=; b=Qz3fhuW2fsvY6LcRG0THATI48gBTm09fN6giGdV3DLTisP+D1oaKPKyUgbBiOfh+HRpYNNWHYRnDOC2mUdYWMHqkPm0uMthHu4nsWITVlumEJ16a+xttsyTnhm0oOsF38Jg3whlHzzUBa4xML0vQ0sw5S45u4DNrEMbDZN54QAw/fBVg/uIhZxrLJ4Nk4cNYPIdX87RQRGZ04OiTvt9AT770DrBdS5DvycrurmqkbfcAAKyFd3bA6pI+cthfYh9BGJA+xHhIyMGfwyg0O1+jzHmuSOf90kaAtMukMG/bXvGm1Xe1YRbA1tow3F2gr9n6pyHB75L7Up8uOmejchGtOg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com; Received: from DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) by AS8PR04MB8802.eurprd04.prod.outlook.com (2603:10a6:20b:42d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6907.22; Thu, 19 Oct 2023 08:36:06 +0000 Received: from DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::d9c0:d907:4d2d:15b3]) by DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::d9c0:d907:4d2d:15b3%7]) with mapi id 15.20.6907.022; Thu, 19 Oct 2023 08:36:05 +0000 Message-ID: <3504781c-a806-335f-a9df-615ed3565e5e@suse.com> Date: Thu, 19 Oct 2023 10:36:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] Support Intel USER_MSR Content-Language: en-US To: "Hu, Lin1" Cc: "Lu, Hongjiu" , "binutils@sourceware.org" References: <20231010072401.1383177-1-lin1.hu@intel.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR0P281CA0231.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:b2::11) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|AS8PR04MB8802:EE_ X-MS-Office365-Filtering-Correlation-Id: a006fd12-6ab9-43f7-55c4-08dbd07e6f68 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: M4kQ9YfVDr4ruQ05ttNYAjZ+L1iwjk1FxRXSL9zaF0sKSpDknpMXRHN2SBcZSUvPJzR1grfW6nm3cbtVASCT6d6pBuRVMlIdyouYlr1X0mmV/54kqdG00E8ZysdnolAqWys79ItNdFJf1qDVfzPJKD2mf9rC2jUNvN0f9UaG4jQGBezSFD5Y9Nx84X53KVCdFBHQRj3p78oqlGeGuxYIVnN2hw6FYZrG9Ql90nRipOB/pUuOx0DGCdhYB1vxOIu83QGufKPQ2lqPXvvEimFQzkBTfiqvI+CT1I1H66sT8otzc+lWPSUrsbQiLbpVW2LE0xp5/aWXl0NEOlP4Eku7pLtLNz6FktnG60iTyuNVVyh1zmu6a/T4739Yg4AFfUhfz907qCtoaPI22AgV1Vonr6O1P/WL8keVZ+SkaQQIUXK2e8Nj+zxM3jkK+XThu5uK6+AOOt21HEVAg/jq/rYuB75RufSELu6UeNqddrn/sIz94LWDYgZXZvbYXMxK5PYs8hp9cAdGz0pWI0iIU7GXFO0kwmsf5SC0Vtx4GoHl0sSJBwdJrCVIx7XFvIwWyC5BauxFHAeaWmq+VQbT0IK/UuiXoE71rM7ppkpCYWTBeR2nAYJdUKWar1VEUTc22Ei1MLsCxaWVb4aTkjSP3kiVMg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR04MB8790.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(346002)(376002)(39860400002)(136003)(396003)(366004)(230922051799003)(186009)(1800799009)(451199024)(64100799003)(83380400001)(66899024)(38100700002)(2616005)(36756003)(6512007)(6916009)(66946007)(54906003)(2906002)(316002)(31696002)(5660300002)(41300700001)(8936002)(8676002)(86362001)(66556008)(4326008)(478600001)(6486002)(53546011)(6506007)(66476007)(26005)(31686004)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RFRHaWpJMXBIM2UwbDk0UUFLNHhhdm1lcXNxaVp4T3BYSVk4M2FWY1dMM3Nr?= =?utf-8?B?N0VhcS95bzQ1WE1kaThzYklvWUtmclNrdVBHbCsvdUFMNXQ0UUpoSkQvQVpK?= =?utf-8?B?YWExNFlOUi9STUM3U2lDQzdNMVdsTEViSG0zSDZRNlhTRUdZUjJZMjlXRGNu?= =?utf-8?B?QnJ0OVB6Y0ZvNmQwaUZETWdJZEJpNjhjbVZCcGtGOWRiK0ZudTcyeWZHSm1C?= =?utf-8?B?M25vMENEWkFDMkR6SzZCQ3FFamhNWlJiUGluTWV2bDg3M3JxQXFBVFRkSy9R?= =?utf-8?B?TTd6bk9DY3h2c3J2cTdOMzJ4Wk5ETDUxZVRQcGRRenNpaitld2drNkJBVWVm?= =?utf-8?B?Z3Nxd3VaU0NTV3JnRXVuZUpEYXhSVnFLVnZwZTd5Ny9LT3hKL1RSdHk3K2xl?= =?utf-8?B?cmwzS20zYi8zNFE3RDZCWEMrVmQrOGp6NmNINDJ4eUJEUU04Q3g1NGhETWpm?= =?utf-8?B?K2tEOXZ5aG9KdXhIQWV5UnIySkxHMkNnOXFZUG9ROXRhSmNJQlQrYUlZVWdx?= =?utf-8?B?SjU5dlJJQzZuQkpWYjhEZTdDS2cxSzRaOERId3RjcGZpZC9SeTNwYkVEU1V3?= =?utf-8?B?MWpIV0V3VUVqZ29tTXhJdW53Mi9WZ0g2c2ZRVjRDeFRtTFRZZUlwdmxIckZt?= =?utf-8?B?QStsU1dpNk5UQTVtdTNYNGxBOVZOdHZESFljeUtlalBWUUpORWwvWGFCekZz?= =?utf-8?B?Vk1pZ1NvbjZCWVlNSDhwcTJ2SlBvS0cwVEJNK2ROZG9hNDNrT0VxZXJCOVY0?= =?utf-8?B?a0dOd0RoLzFpa2k3Nyt4ZTBRRUp1SUlsNFpuZ0tQSEY1MlFnc0t5VUZQUTRC?= =?utf-8?B?VkhIMXEwSkhCaTFpWFRvcGdSWHNjdEJOdzJ0MnhQdzFxbXBuRFc1UEQzV2dO?= =?utf-8?B?cnJqVDhQR0hWNGpyTVFzQnRCclFMdlRkWXVWQm53dGZhUWVyYXdGZ1hIaXR6?= =?utf-8?B?UkZaVFF2MERJTEdpWkFOcGVWa3hBU1NkRUkzRE4rUjE0dDNOS1hHUE9ac25U?= =?utf-8?B?eDV5WUZDR3dOc0Fpb2hwQ3ZVV3NMSmxqMi9SN3ZGbDNCaGliR0Q2K1hodWRD?= =?utf-8?B?Um8zbkhCSU0rRzE4N1RzUnVqTVdyZ1NlcTg0alJ3RUszeUR6enFqcDg0eEVi?= =?utf-8?B?cGRvYlFiNkVtb2RqUE1wU1M0Q0E2dE5meUErZ2tJMzlzeG4yUTlCTzM4UGdz?= =?utf-8?B?cDA3ME04VmR1ZXArSFNoQURXZCtPQnRzYkc4K0hVbUl5K2UrK1ZBNVY5eldR?= =?utf-8?B?Yi9ZN3FIUW1FZUxkWHI0QWhHRFhsR3VzY1lXWEFzSU9DTzgrUXd3UWRFSnlo?= =?utf-8?B?MDBhVStrY2x4S3dqWm5Mc1ZYTS9La3k3V2haQ0RZTVo0YnREcjRIN0UzNnZ3?= =?utf-8?B?QksxN0JmSlpVNEZRaDQzVEZvbmRBNE9YaE56cUJRMkZlL2xpOWVjNmd4dEpF?= =?utf-8?B?cWdyTldaejBmeTlSbm5XcXl6VEpTSDVVWjEyeDBySkpIbXowd0g1RHZ3Vkpw?= =?utf-8?B?YmwzY1YyRkoxenYyZ1h0dzN6aXpwZnFQUjMwbmZkRUxWK3BhbndmcXNTSFdj?= =?utf-8?B?L2ViRXZHTS9PYTRveXprcmdZbFl6NHNXYmc1NXVtc1NEQWpoR3FXRm15Y0xn?= =?utf-8?B?MTh6d2hOU21UTURkNW1KSzdCSDVUNXM3OVNNdlVNZlRVUXI5emtwZG9sa1Nq?= =?utf-8?B?ZkRNTmZXN1R3QldZR2x2OVJ0UEUxbmJCaFNNRmtUbzIwc2xBc1VycnNWdENv?= =?utf-8?B?RXg4Nm9wVUk1UVQ1Tm9pR1FYdHFQWEFkNk82bVE5VFhzdys0cGFUN2RBSG5a?= =?utf-8?B?UzJpV25BVmQ1Y211dmtjcXRXaUdkeExNQzRJN3E4NFJHNjdvekV6ME1wS3lB?= =?utf-8?B?YzIxMHV2aEFEdjZtaG1od2x1bWE0OUxERUY5TWNPSlo0VUdKL1JKZkJUZUFS?= =?utf-8?B?bmpyUU9uNFhyT3BTOGExSXhlWXErSExseDdiMC9xeVhib0QyVm1yeUI1MkZV?= =?utf-8?B?VFl6TnNpSlNoREJZQTBWZkhwb2ZrQzRWRWNUY084NjNaSC9kTUtZcnFzVWsy?= =?utf-8?B?M29lOXcrMWRQZFd6ams0bWpZTHlXT1hua09odWMvV2xjWnByUkN6Vk8yR2VU?= =?utf-8?Q?6maXWOAKG7noMZAC1uT6GXZ9u?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: a006fd12-6ab9-43f7-55c4-08dbd07e6f68 X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2023 08:36:05.7812 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ODjEW6R6d2ZuPyJt3stK3YsVYGlocBLlDlWcr5H0mK9ULbHO7hpb+3f5u8n9SUQNh4+iel+n1x0SemOVTlT+oA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB8802 X-Spam-Status: No, score=-3027.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LOTS_OF_MONEY,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,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: On 18.10.2023 09:51, Hu, Lin1 wrote: > Thanks for your review. I responded individually under each comment. > Attached is the modified version. Please can you send proper new versions, to allow easy commenting? > -----Original Message----- > From: Jan Beulich > Sent: Monday, October 16, 2023 8:11 PM > > On 10.10.2023 09:24, Hu, Lin1 wrote: >> @@ -8752,6 +8755,18 @@ build_modrm_byte (void) >> source = v; >> v = tmp; >> } >> + if (i.tm.opcode_modifier.operandconstraint == SWAP_SOURCE_DEST) >> + { >> + if (dest == (unsigned int) ~0) >> + source = source ^ 1; >> + else >> + { >> + unsigned int tmp = source; >> + >> + source = dest; >> + dest = tmp; >> + } >> + } > >> Why is this needed? There's only a single register operand in both affected insn forms (see comment below on the 2-register form). > Furthermore I think it would be easier if you "canonicalized" the early immediate to be the 1st operand, such that for all other purposes immediates remain first. > >> As a cosmetic nit: Please have a blank line ahead of the if() block (if it needs to stay). > > Indeed, I've only kept the part that deals with a single register. Do you mean to complain to the person who designed the insn. Unfortunately, that's impossible. I'm having trouble connecting your reply to what I wrote. No, I do not mean to complain; I can certainly see why the immediate is wanted as first (Intel) / last (AT&T) operand. I'm also not happy about the new change to build_modrm_byte(). When asking to "canonicalize" operands, I meant to gave this generalized, with SWAP_SOURCE_DEST dropped completely. (This will then also save me from complaining about a missing blank in SwapSourceDest's #define.) >> --- /dev/null >> +++ b/gas/testsuite/gas/i386/x86-64-user_msr.s >> @@ -0,0 +1,15 @@ >> +# Check 64bit USER_MSR instructions >> + >> + .allow_index_reg >> + .text >> +_start: >> + urdmsr %r14, %r12 #USER_MSR >> + urdmsr $51515151, %r12 #USER_MSR >> + uwrmsr %r12, %r14 #USER_MSR >> + uwrmsr %r12, $51515151 #USER_MSR >> + >> +.intel_syntax noprefix > >> Nit: Please indent directives. > Have removed these comments. Neither does your reply fit here, nor did you what I've asked for here (in addition to the earlier, wider request of dropping meaningless comments). >> + urdmsr r12, r14 #USER_MSR >> + urdmsr r12, 51515151 #USER_MSR >> + uwrmsr r14, r12 #USER_MSR >> + uwrmsr 51515151, r12 #USER_MSR > >> I think varying registers slightly more (such that each two-register form has one low-8 and one high-8 operand, totaling to two forms each to prove that the REX.[RB] bits are also correctly dealt with) would be better. > > I have added some other tests here. Thanks. >> @@ -618,6 +620,8 @@ enum >> w_mode, >> /* double word operand */ >> d_mode, >> + /* double word operand 0 */ >> + d_0_mode, > >> Why is this needed? IOW why does d_mode not do? Or alternatively why isn't this a name indicating that it's an unsigned 32-bit value (as opposed to other 32-bit immediates in 64-bit mode)? > > I want to output imm32 first, but modrm byte is behind imm32, so I need to skip modrm for the moment. If I use { "uwrmsr", { Id, Eq }, 0} Id will read modrm byte. The mode is for a imm32 not an unsigned 32-bit value, so its name doesn't indicate that it's an unsigned integer. But the immediate is an unsigned 32-bit one. Signed ones would be sign- extended, which isn't the case here (or else the range 0x80000000 ... 0xffffffff wouldn't form valid MSR numbers). >> @@ -845,6 +849,7 @@ enum >> REG_VEX_0FAE, >> REG_VEX_0F3849_X86_64_L_0_W_0_M_1_P_0, >> REG_VEX_0F38F3_L_0, >> + REG_VEX_MAP7_F8_L_0_W_0_M_1, >> >> REG_XOP_09_01_L_0, >> REG_XOP_09_02_L_0, >> @@ -893,8 +898,10 @@ enum >> MOD_0FC7_REG_6, >> MOD_0FC7_REG_7, >> MOD_0F38DC_PREFIX_1, >> + MOD_0F38F8, >> >> MOD_VEX_0F3849_X86_64_L_0_W_0, >> + MOD_VEX_MAP7_F8_L_0_W_0, >> }; > >> As before - no new mod_table[] entries please which don't have both branches populated. > > Have removed it. But you're using Eq there, i.e. permitting memory operands as well. What (I think) you want is Rq. For consistency this may then also want using in the new PREFIX_0F38F8_M_1_X86_64 entry. But of course you need to be careful about the collision with Nq. >> @@ -6791,6 +6839,297 @@ static const struct dis386 vex_table[][256] = { >> { Bad_Opcode }, >> { Bad_Opcode }, >> }, >> + /* VEX_MAP7 */ >> + { >> + /* 00 */ >> + { Bad_Opcode }, > >> I wonder whether adding a full new table (rather than some special case >> code) is really a god use of space. Of course if you know that more of it will be populated in the not too distant future ... > > I don't know, I'm just treating the new opcode_space MAP7 like other opcode_space. I'm afraid that "I don't know" is not an answer here. You can basically take two positions: Mine (waste of space) or you justify why the extra space used (and the extra runtime relocations added) aren't of concern. >> @@ -11248,6 +11609,20 @@ get32s (instr_info *ins, bfd_vma *res) >> return true; >> } >> >> +/* The function is used to get imm32, when imm32 is operand 0, and >> +ins only has 2 operands. */ static bool >> +get32_operand0 (instr_info *ins, bfd_vma *res) { >> + >> + if (!fetch_code (ins->info, ins->codep + 5)) >> + return false; >> + *res = *(ins->codep++ + 1) & (bfd_vma) 0xff; >> + *res |= (*(ins->codep++ + 1) & (bfd_vma) 0xff) << 8; >> + *res |= (*(ins->codep++ + 1) & (bfd_vma) 0xff) << 16; >> + *res |= (*(ins->codep++ + 1) & (bfd_vma) 0xff) << 24; >> + return true; >> +} > >> Instead of this (which assumes ModRM.mod == 3) I think you want to arrange for dealing with ModRM first. We already have OP_Skip_MODRM() for such needs, which you could use in a first "hidden" operand. > > I want to output imm32 first, but modrm byte is behind imm32, so I need to skip modrm for the moment. but I can't use OP_Skip_MODRM to deal with my problem, If I use it, I should add ins->codep-- at the end of get32_operand0. get32_operand0() should go away imo; at the very least I don't agree with special casing it being operand 0 (which, as you realize, is true only in the textual representation, and only in Intel syntax, but in particular not in the encoding). It may be necessary to special case it being an unsigned immediate, but get32() already fits that purpose. >> @@ -3346,3 +3349,12 @@ erets, 0xf20f01ca, FRED|x64, NoSuf, {} eretu, >> 0xf30f01ca, FRED|x64, NoSuf, {} >> >> // FRED instructions end. >> + >> +// USER_MSR instructions. >> + >> +urdmsr, 0xf20f38f8, USER_MSR|x64, >> +Modrm|IgnoreSize|SwapSourceDest|NoSuf, { Reg64, Reg64 } > >> Iirc RegMem is the attribute to use here, not any new one. > > Indeed. > >> +urdmsr, 0xf2f8/0, USER_MSR|x64, >> +Modrm|Vex128|VexMap7|VexW0|IgnoreSize|NoSuf, { Imm32S, Reg64 } > >> This and ... > >> +uwrmsr, 0xf30f38f8, USER_MSR|x64, Modrm|IgnoreSize|NoSuf, { Reg64, >> +Reg64 } uwrmsr, 0xf3f8/0, USER_MSR|x64, >> +Modrm|Vex128|VexMap7|VexW0|IgnoreSize|SwapSourceDest|NoSuf, { Reg64, >> +Imm32S } > >> ... this needs to use Imm32, not Imm32S. I understand this is going to cause complications elsewhere, but we can't afford getting this wrong. I see you've corrected this, but it doesn't look to me as if the match_template() change is actually going to do the job. You can't change i.types[] without looking at the actual values. I think this needs dealing with in optimize_imm() and/or finalize_imm() (irrespective of it's name more likely the former, but knock-on adjustments to the latter may then turn out to be needed). >> Also in all forms I think you don't mean IgnoreSize, but NoRex64. > > Have modified them. Hmm, I may have mislead you: NoRex64 is meaningless on VEX encodings. There only the IgnoreSize needed dropping. I'm sorry. Jan