From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on2040.outbound.protection.outlook.com [40.107.15.40]) by sourceware.org (Postfix) with ESMTPS id 3E004385841D for ; Tue, 7 Nov 2023 14:53:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3E004385841D 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 3E004385841D Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.15.40 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699368833; cv=pass; b=fhk1IT+WbwH2d1rYhTiYRcI2ZsyTUtgLkl0s4nPluUWs0EHnqjCBbllGW0XAWrsH6P6MZgmr25k9AK4cpzz0XLUOo7LDM5w9onMbDJVI5nCpCesb4bW/b0wISwSmA70XnMN64cibWPB8gEHsPTdYrbdauEj6qMwcjMY+8rINIf8= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699368833; c=relaxed/simple; bh=zZ4nDyV6mLZvHl0hHrOdmBPo802Nc1WYUb3EVFjGna4=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=SmLTKIb/A8UFhMq0CN6k/aIY6YJaAVxAM7pW80E3ellTa6T6l/7DFTZFagsgEa1Ulmh0RZcTHucmU39ENrxaBi2DA9x5006YhelSAJ1Gwv2KBSd9Ny+ZcFENNEPcqLRF9XzR/r4UUG31Gm3A5urJn3QYiJERBOT0iPTVyZBIFto= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FzCOo9/9PL7FIdpP+aeYarsnlNK++XGmK1eafg/81efg1SjW6fUZURP8RKZ95TO6sYW7WHdtaEhhbQ8KAmY/Cgv3EhcugfaK+xyMdxQwqb+N8x5iZ2ua2r/i+FdAKySeMEQgj8y+e9cKwzzOcD3AW00GGBxlsETVwA6f9cJKUZcLWCouqbFsOPC3AzduYK0/B7troLL5gbQhpUKyFqBOnowO/X6Ryods6TJbjp+vaS1ttTDARSYhZPQqfwWOWqKjtgy//8qJKFZVKwEdMJ+WkdVZF0K6HUElgGFD7CLhCtoruzkCn0704JUb+obqvTrJBi5DuVgxtanTX5Gd1Mganw== 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=avn8nIbkFnSnK8PwWFuUnbvLfqWoREYlHDmtX1gFy7M=; b=hUSUujbJrv0rkRtoCP1aYQsqwVLEZKfo2gVWawyFBAnABJ/y01YUHIcnwgdqR5WxAZp1ylqfcgIlbU8eQZKMJ0mdC5jy2WdaL1Mucm3meCJpgr8nrv90rUFJhsGMKW4gwndW6i1YdkJxuKZubw0PT34muv9v4uhYk0mG6wCru4udZmDiOZKcDQsCbwPD6CPsPcdM8zxQB3aevP9sNQv/lcZkcJ7C1hGVyhUCw19ApgTeYtfkwa6vvLsTlefeXC2SMM+4bgP9f3ccnM94mMcRtfkVXqAl7rZwcOqpLCdGyTbnS1i4X6r7QzwKKNUuio0Jrzjd+cDwdgXgNt7z1cQ7iA== 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=avn8nIbkFnSnK8PwWFuUnbvLfqWoREYlHDmtX1gFy7M=; b=wP2CfDlvWdpqu2PL/VKRBOJlqBiF6nMccfXwWaF40PStVrg4sskwHAGOherOPFXwt5mgYVgmYnpyl6DdkFnBUMU+rnqqyDX5KhwdJZWnkPr6UkyYvEfzhov9k0EyRq5eV9J5X87vEI6JsTbbmoT9TrRIWJqGhJYIJe3kn86cZc4Qpopnn+086n3xdbKddmrsSrK/UZub5A32bqZ6wRiCJIMSUoLflum9rEBKowZeGIuFmDX/kGVIal9WZCe/Ev0+rzyitB/22yzzYoJVVeESQx+Hf5+i2qWSKe8nLCzwfRz3NkTJ8f65YFAUEwTLuieUxpNiV0/2ldqRiNfkttc2pA== 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 GVXPR04MB9975.eurprd04.prod.outlook.com (2603:10a6:150:118::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.16; Tue, 7 Nov 2023 14:53:45 +0000 Received: from DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::eb8e:fa24:44c1:5d44]) by DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::eb8e:fa24:44c1:5d44%3]) with mapi id 15.20.6977.017; Tue, 7 Nov 2023 14:53:45 +0000 Message-ID: <4aebadde-7cba-050e-d2eb-188d6216c566@suse.com> Date: Tue, 7 Nov 2023 15:53:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH V2 3/8] Support APX GPR32 with extend evex prefix Content-Language: en-US To: "Cui, Lili" Cc: "Lu, Hongjiu" , "binutils@sourceware.org" References: From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR4P281CA0056.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:cc::16) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|GVXPR04MB9975:EE_ X-MS-Office365-Filtering-Correlation-Id: 303a41ae-94ac-400f-e72e-08dbdfa15764 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lm3UFHcKyL1F0i/l87XuRNxU24a6RIR/Ys+3x3hyePRxjK+u1It/xQfqHK7GtpoMyXtv/BY7/W5SDlUUyvlaRyScGGTtDXJ3a8ItCf/8M99jIn4IrzainOxBRz9J5ny65SL/6d6jOXt3h04gDMuDC/EKudlYfOBOs+TgNYxxs9V/cQnuWaxZleppM1NA7ytVUSUyBZBgPz3ddeb4UNFFvD5qUtS+js1KMhpQ9duJFq59zvX/qX423H58MnLoYJsmBRamH1bbtgiP4A4yCT3zDYwtopi9bNAYtFXUORCP7PsUYE/WD2yXNx0foJorEncgXbR6yy2LaWKDqF830w6g8+2tQ8eD9dzCfc5/r88Eiyfiaj4gGKIjKh5CfFSe8t7usxXPnWhhY8RfLMLGwrSQVt2564bBKF6VscY9C5dd0+xU9sKQ+JiX5s1AELWeyYzdT589dVKKcWEjinBa8N3YiXN1vRd0p0Y+LRw3JB/AlRSxZUTzEFDd3rP3gsHRsyf+DowSC7xAPb9e9y+p2gBXi9ZdgPquLkTM3lw8iHVeMPD6exNtYVd/jZALGDVNmf4WvzfDFU105aX89U78PS2bd1AWzFVBR4BzhsETPYcwQ1YXgMB9BQ6RG8Z5i56XpuollefZxlf15ERgMnPf7KoboSMaR45TVkn62dT9ogr8KM02LCRdW4ZxB2jVa3PVKEXf 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)(39860400002)(376002)(366004)(136003)(396003)(346002)(230273577357003)(230922051799003)(230173577357003)(451199024)(64100799003)(186009)(1800799009)(38100700002)(8676002)(53546011)(36756003)(6506007)(41300700001)(66946007)(30864003)(6512007)(66556008)(66476007)(54906003)(6916009)(8936002)(2906002)(4326008)(6486002)(316002)(5660300002)(478600001)(2616005)(26005)(83380400001)(31696002)(86362001)(31686004)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cjR6NDBxNnlEVU5xQlcxSkp2YUh3VFlZSVBMQXlzRnJ2SnR3YklRbGJUeENp?= =?utf-8?B?aHdzSHpmNGI5L1BnaTVoTGdJZHJZV2t2MjZpckNSS2JCbGVlMTNjYzJDNUNh?= =?utf-8?B?c1dpNjVRbU55d1QvKzFlQmdiclZKZ3g1UHluTGI0ZnduVnQxdXU2dzcrQ3p4?= =?utf-8?B?Zm1vdzFCSjFNNEhTaFg4QUdJWWFlOEVDSW1zQVEzSTN4cFU3SmxXU056UWFw?= =?utf-8?B?MEo5dEsxcXFQLzVUWjB6anZQbStvNVFINDlDbmsvcDdMZkNYSWpEWEhsODEr?= =?utf-8?B?eDQxQWttZmplOGFaSlRCL2lpaHBCMmFLU2tJcnZvMmNVb0RqRXRJUkZaMDAx?= =?utf-8?B?R1N2WEtIYkV0c295QlY2RWJwbFFSbVJiWjM0eFVFYWhHTHI0SEZlZUZRWWlY?= =?utf-8?B?dk90T09JVWJTcEhnd3JiM0FYWGZEa1VyK3FJYXVETnJONlNlQU41K1hjZGxD?= =?utf-8?B?ZjF3dXRrZ2xBTHU0TzdmalJkU09IdG1XbWh6VEt1ei9PYVZjRndFcEFOL3k5?= =?utf-8?B?di9OUzRaZkpGWjRUUUk0VmlOdlo5b0QxbTJiYWc4djQ2OTZMZVgyc1htNk1a?= =?utf-8?B?MGhQam9jb2ZIcWdJWVp2U0oxdXIvTXlvSDJ6aEltcTQ4a0Z3cHlVQkFrYUxK?= =?utf-8?B?NVBFK0pwSjZKWW5GK2VjRFhoZDd4aXZnS1BiSGRUVFNpZUJhUEkxUWtzNkgw?= =?utf-8?B?enVieUlObG5EVVlPdndCNGFvSXZrdnhIVUQ2cC91L2JNeHExWEx6K1E4MCtV?= =?utf-8?B?NUpLNjAyRFVpSnFzVUxGamVzSGh3RFNqelF4bjZaZ3lrYVU3N01uWlFuSGhL?= =?utf-8?B?UDE4YjdQcTRlMlBCVVFGSjNPYWROdXdLUTFLREJuaTU0aVVnaVNkVE1zR2VH?= =?utf-8?B?VUJvOHBKM0VFMUgyODV6OThkUXpUYS81ZnRaMmJJWGV6ODFrSG4wazg1WWRX?= =?utf-8?B?UVhiM25PVTIrSzIxcFY1ZC84dDZGOS9iNmU4ZjNQRkFsV2RDZnJkdlkxWXVh?= =?utf-8?B?TTE3QVR1ZHlLWnhINVE3WXVrcmNOb244eVJuYVN6UWdnZURmbUg5VVJKRjRJ?= =?utf-8?B?WXNJNWtzd0gvbWZ6clV4TWhTanhPRkV3bmkzM003NmtJSGxaejRmRllUOG1i?= =?utf-8?B?MVo0VUlJS0oraDZnWG1aV3JLc0hmQm10U1llYzdaUm5ML2EyckxOcVZSczhx?= =?utf-8?B?eVNiUWpyUmx0U29uTkNIVGkvVzloTjlDS0Y2RnhBMjNJakNVK05yMkZwb1M3?= =?utf-8?B?UlJyZ2s3SHl2a2V6ZWQ3VWtaRjJwVkprclBXSTVlM1dFRWFveFkwSDZRQ0lD?= =?utf-8?B?REpOQXFYNDJhL0htWW9xUUtmcUNGa0hjcERmVlVuVTBXcjQzUk5yU1l4dXlB?= =?utf-8?B?SUtOYWx0c3l1eDhja2RxdG5ia2VucUwwOEx4eFM3WTZiMW0vQzJocGs5R2xj?= =?utf-8?B?NXV3R3dvT0J5bmFxRGtGK0YvQ2xCbiswdGtCL3owN0hrcmc3bHRJSkc5ZDRN?= =?utf-8?B?TGlUZnUzZFpXSFBUQlJRYUVOOURyclhkSnljVGVWbHVkczVXNmswYmNLckRp?= =?utf-8?B?bjlJaTVmRlg5RGdrRGNtTDZGbGp1amE4QXpuaGdpeE9yUWdPdnZlNWdKR3VJ?= =?utf-8?B?NUIrd2hLUHVhOGw1a1hpZ0E1MFVZc2tIZ3p0NUZXUExuZ1cxSTZ1VnkrcWRt?= =?utf-8?B?Zk5oVmo5bTgySUtob05GamlieFVRbEhlSWxhWEdpU0dhV1R1L1JsVUtJVjFW?= =?utf-8?B?cTlLQmRXMTc0UE9xOU1IU3g4WmREL0JyVHpEaUZoN0VNRWFtb3FJMXN4SjZN?= =?utf-8?B?TWhBWjRhQnB3RHdnck9TSXRjRXNtZ3lTR3RjV3kyNHpDVEVHSmJ2b0M3amNu?= =?utf-8?B?N1MwcDdVekxNWVlXTTlKMjk2aHBNU1NneWsxU1RQZGRtQUZhTXZ6bExuWHlW?= =?utf-8?B?Zmtib0wzQm1XelFWMGZmMkR5R2tJdFVVN1dSK2xJNjJBSDNqVlI4aHRtY29D?= =?utf-8?B?QTJnMFFyTTJWcVR1ODhESlhVTzlhQ3Bsczc5WWZzNkQ2dHJVRlRraGNadktw?= =?utf-8?B?dUI0T3hubWNvQjUvZmJYekc0c2NWaEppMkRvczZBRlJ0VDFDOVMvL2VyR2Zv?= =?utf-8?Q?KE6il/FxiSVVYbI/oYO2qopu8?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 303a41ae-94ac-400f-e72e-08dbdfa15764 X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2023 14:53:45.3706 (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: QZwkncdA7UAFsBggLNdsYk3P0uUOyD8iSwmJk1G4AHTWx+oNST/eAClRHCwm5dRkqunrO3UnyA0xUe44On3bDw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR04MB9975 X-Spam-Status: No, score=-3027.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 03.11.2023 17:50, Cui, Lili wrote: > --- a/gas/testsuite/gas/i386/x86-64-inval-movbe.l > +++ b/gas/testsuite/gas/i386/x86-64-inval-movbe.l > @@ -1,29 +1,30 @@ > .*: Assembler messages: > -.*:4: Error: .* > .*:5: Error: .* > .*:6: Error: .* > .*:7: Error: .* > .*:8: Error: .* > -.*:11: Error: .* > +.*:9: Error: .* > .*:12: Error: .* > .*:13: Error: .* > .*:14: Error: .* > .*:15: Error: .* > +.*:16: Error: .* > GAS LISTING .* > > > [ ]*1[ ]+\# Check illegal movbe in 64bit mode\. > [ ]*2[ ]+\.text > -[ ]*3[ ]+foo: > -[ ]*4[ ]+movbe \(%rcx\),%bl > -[ ]*5[ ]+movbe %ecx,%ebx > -[ ]*6[ ]+movbe %bx,%rcx > -[ ]*7[ ]+movbe %rbx,%rcx > -[ ]*8[ ]+movbe %bl,\(%rcx\) > -[ ]*9[ ]+ > -[ ]*10[ ]+\.intel_syntax noprefix > -[ ]*11[ ]+movbe bl, byte ptr \[rcx\] > -[ ]*12[ ]+movbe ebx, ecx > -[ ]*13[ ]+movbe rcx, bx > -[ ]*14[ ]+movbe rcx, rbx > -[ ]*15[ ]+movbe byte ptr \[rcx\], bl > +[ ]*3[ ]+\.arch \.noapx_f > +[ ]*4[ ]+foo: > +[ ]*5[ ]+movbe \(%rcx\),%bl > +[ ]*6[ ]+movbe %ecx,%ebx > +[ ]*7[ ]+movbe %bx,%rcx > +[ ]*8[ ]+movbe %rbx,%rcx > +[ ]*9[ ]+movbe %bl,\(%rcx\) > +[ ]*10[ ]+ > +[ ]*11[ ]+\.intel_syntax noprefix > +[ ]*12[ ]+movbe bl, byte ptr \[rcx\] > +[ ]*13[ ]+movbe ebx, ecx > +[ ]*14[ ]+movbe rcx, bx > +[ ]*15[ ]+movbe rcx, rbx > +[ ]*16[ ]+movbe byte ptr \[rcx\], bl To avoid the need to fiddle with this file, did you consider changing the test's command line options instead? In any event ... > --- a/gas/testsuite/gas/i386/x86-64-inval-movbe.s > +++ b/gas/testsuite/gas/i386/x86-64-inval-movbe.s > @@ -1,5 +1,6 @@ > # Check illegal movbe in 64bit mode. > .text > + .arch .noapx_f > foo: > movbe (%rcx),%bl > movbe %ecx,%ebx ... the comment here wants expanding, to (briefly) mention the deliberate exclusion of APX. > --- a/opcodes/i386-dis-evex-len.h > +++ b/opcodes/i386-dis-evex-len.h > @@ -62,6 +62,16 @@ static const struct dis386 evex_len_table[][3] = { > { REG_TABLE (REG_EVEX_0F38C7_L_2) }, > }, > > + /* EVEX_LEN_0F38F2 */ > + { > + { "andnS", { Gdq, VexGdq, Edq }, 0 }, > + }, There's no sign of a prefix decode step here. > --- a/opcodes/i386-dis-evex-mod.h > +++ b/opcodes/i386-dis-evex-mod.h > @@ -1 +1,43 @@ > /* Nothing at present. */ This comment needs to go away when new stuff is added here. However, I'm sure I requested before that no new entries be put here which have only one of their two slots populated. The reg-only and mem-only aspects can be expressed via proper choice of operand specifiers, at least in almost all cases. Note how you already use ... > + /* MOD_EVEX_MAP4_DA_PREFIX_1 */ > + { > + { Bad_Opcode }, > + { "encodekey128", { Gd, Ed }, 0 }, > + }, > + /* MOD_EVEX_MAP4_DB_PREFIX_1 */ > + { > + { Bad_Opcode }, > + { "encodekey256", { Gd, Ed }, 0 }, > + }, > + /* MOD_EVEX_MAP4_DC_PREFIX_1 */ > + { > + { "aesenc128kl", { XM, M }, 0 }, > + }, > + /* MOD_EVEX_MAP4_DD_PREFIX_1 */ > + { > + { "aesdec128kl", { XM, M }, 0 }, > + }, > + /* MOD_EVEX_MAP4_DE_PREFIX_1 */ > + { > + { "aesenc256kl", { XM, M }, 0 }, > + }, > + /* MOD_EVEX_MAP4_DF_PREFIX_1 */ > + { > + { "aesdec256kl", { XM, M }, 0 }, > + }, > + /* MOD_EVEX_MAP4_F8_PREFIX_1 */ > + { > + { "enqcmds", { Gva, M }, 0 }, > + }, > + /* MOD_EVEX_MAP4_F8_PREFIX_2 */ > + { > + { "movdir64b", { Gva, M }, 0 }, > + }, > + /* MOD_EVEX_MAP4_F8_PREFIX_3 */ > + { > + { "enqcmd", { Gva, M }, 0 }, > + }, ... M in many entries anyway. These can move one level up without needing further adjustment. For all of the above, however, an EVEX.W decode step looks to be missing. Interestingly the doc consistently omits the (presumably) .W0 suffix for these, having merely a trailing dot there. The issue (doc and/or code) is present elsewhere as well. > + /* MOD_EVEX_MAP4_F9 */ > + { > + { "movdiri", { Edq, Gdq }, 0 }, > + }, Missing PREFIX_OPCODE? > --- a/opcodes/i386-dis-evex-prefix.h > +++ b/opcodes/i386-dis-evex-prefix.h > @@ -338,6 +338,75 @@ > { "vcmpp%XH", { MaskG, Vex, EXxh, EXxEVexS, CMP }, 0 }, > { "vcmps%XH", { MaskG, VexScalar, EXw, EXxEVexS, CMP }, 0 }, > }, > + /* PREFIX_EVEX_MAP4_66 */ > + { > + { "wrssK", { M, Gdq }, 0 }, > + }, > + /* PREFIX_EVEX_MAP4_D8 */ > + { > + { "sha1nexte", { XM, EXxmm }, 0 }, > + { REG_TABLE (REG_EVEX_MAP4_D8_PREFIX_1) }, > + }, > + /* PREFIX_EVEX_MAP4_DA */ > + { > + { "sha1msg2", { XM, EXxmm }, 0 }, > + { MOD_TABLE (MOD_EVEX_MAP4_DA_PREFIX_1) }, > + }, > + /* PREFIX_EVEX_MAP4_DB */ > + { > + { "sha256rnds2", { XM, EXxmm, XMM0 }, 0 }, > + { MOD_TABLE (MOD_EVEX_MAP4_DB_PREFIX_1) }, > + }, > + /* PREFIX_EVEX_MAP4_DC */ > + { > + { "sha256msg1", { XM, EXxmm }, 0 }, > + { MOD_TABLE (MOD_EVEX_MAP4_DC_PREFIX_1) }, > + }, > + /* PREFIX_EVEX_MAP4_DD */ > + { > + { "sha256msg2", { XM, EXxmm }, 0 }, > + { MOD_TABLE (MOD_EVEX_MAP4_DD_PREFIX_1) }, > + }, > + /* PREFIX_EVEX_MAP4_DE */ > + { > + { Bad_Opcode }, > + { MOD_TABLE (MOD_EVEX_MAP4_DE_PREFIX_1) }, > + }, > + /* PREFIX_EVEX_MAP4_DF */ > + { > + { Bad_Opcode }, > + { MOD_TABLE (MOD_EVEX_MAP4_DF_PREFIX_1) }, > + }, > + /* PREFIX_EVEX_MAP4_F0 */ > + { > + { "crc32A", { Gdq, Eb }, 0 }, > + { "invept", { Gm, Mo }, 0 }, > + }, > + /* PREFIX_EVEX_MAP4_F1 */ > + { > + { "crc32Q", { Gdq, Ev }, 0 }, > + { "invvpid", { Gm, Mo }, 0 }, > + { "crc32Q", { Gdq, Ev }, 0 }, > + }, > + /* PREFIX_EVEX_MAP4_F2 */ > + { > + { Bad_Opcode }, > + { "invpcid", { Gm, M }, 0 }, > + }, As opposed to the entries further up, INV* are indeed WIG, so validly don't decode EVEX.W. > + /* PREFIX_EVEX_MAP4_F8 */ > + { > + { Bad_Opcode }, > + { MOD_TABLE (MOD_EVEX_MAP4_F8_PREFIX_1) }, > + { MOD_TABLE (MOD_EVEX_MAP4_F8_PREFIX_2) }, > + { MOD_TABLE (MOD_EVEX_MAP4_F8_PREFIX_3) }, > + }, > + /* PREFIX_EVEX_MAP4_FC */ > + { > + { "aadd", { Mdq, Gdq }, 0 }, > + { "axor", { Mdq, Gdq }, 0 }, > + { "aand", { Mdq, Gdq }, 0 }, > + { "aor", { Mdq, Gdq }, 0 }, > + }, This looks to match the PREFIX_0F38FC entry. > --- a/opcodes/i386-dis-evex-reg.h > +++ b/opcodes/i386-dis-evex-reg.h > @@ -49,3 +49,17 @@ > { "vscatterpf0qp%XW", { MVexVSIBQWpX }, PREFIX_DATA }, > { "vscatterpf1qp%XW", { MVexVSIBQWpX }, PREFIX_DATA }, > }, > + /* REG_EVEX_0F38F3_L_0 */ > + { > + { Bad_Opcode }, > + { "blsrS", { VexGdq, Edq }, 0 }, > + { "blsmskS", { VexGdq, Edq }, 0 }, > + { "blsiS", { VexGdq, Edq }, 0 }, > + }, Compared to the REG_VEX_0F38F3_L_0 entry this lacks PREFIX_OPCODE, but then the question is why you do not re-use that entry in the first place. > + /* REG_EVEX_MAP4_D8_PREFIX_1 */ > + { > + { "aesencwide128kl", { M }, 0 }, > + { "aesdecwide128kl", { M }, 0 }, > + { "aesencwide256kl", { M }, 0 }, > + { "aesdecwide256kl", { M }, 0 }, > + }, How is this different from the REG_0F38D8_PREFIX_1 entry? > --- /dev/null > +++ b/opcodes/i386-dis-evex-x86-64.h > @@ -0,0 +1,140 @@ > + /* X86_64_EVEX_0F90 */ > + { > + { Bad_Opcode }, > + { VEX_LEN_TABLE (VEX_LEN_0F90) }, > + }, > + /* X86_64_EVEX_0F91 */ > + { > + { Bad_Opcode }, > + { VEX_LEN_TABLE (VEX_LEN_0F91) }, > + }, > + /* X86_64_EVEX_0F92 */ > + { > + { Bad_Opcode }, > + { VEX_LEN_TABLE (VEX_LEN_0F92) }, > + }, > + /* X86_64_EVEX_0F93 */ > + { > + { Bad_Opcode }, > + { VEX_LEN_TABLE (VEX_LEN_0F93) }, > + }, > + /* X86_64_EVEX_0F3849 */ > + { > + { Bad_Opcode }, > + { VEX_LEN_TABLE (VEX_LEN_0F3849_X86_64) }, > + }, > + /* X86_64_EVEX_0F384B */ > + { > + { Bad_Opcode }, > + { VEX_LEN_TABLE (VEX_LEN_0F384B_X86_64) }, > + }, > + /* X86_64_EVEX_0F38E0 */ > + { > + { Bad_Opcode }, > + { "cmpoxadd", { Mdq, Gdq, VexGdq }, PREFIX_DATA }, > + }, This and its sibling entries look to again fully match X86_64_VEX_0F38E. > --- a/opcodes/i386-dis-evex.h > +++ b/opcodes/i386-dis-evex.h >[...] > @@ -1113,19 +1113,19 @@ static const struct dis386 evex_table[][256] = { > { Bad_Opcode }, > { Bad_Opcode }, > { Bad_Opcode }, > - { Bad_Opcode }, > + { "sha1rnds4", { XM, EXxmm, Ib }, 0 }, PREFIX_OPCODE? EVEX.W? > { Bad_Opcode }, > { Bad_Opcode }, > { Bad_Opcode }, > /* D8 */ > - { Bad_Opcode }, > - { Bad_Opcode }, > - { Bad_Opcode }, > - { Bad_Opcode }, > - { Bad_Opcode }, > - { Bad_Opcode }, > - { Bad_Opcode }, > - { Bad_Opcode }, > + { PREFIX_TABLE (PREFIX_EVEX_MAP4_D8) }, > + { "sha1msg1", { XM, EXxmm }, 0 }, Again. > --- a/opcodes/i386-dis.c > +++ b/opcodes/i386-dis.c >[...] > @@ -4522,12 +4594,13 @@ static const struct dis386 x86_64_table[][2] = { > { "cmpnlexadd", { Mdq, Gdq, VexGdq }, PREFIX_DATA }, > }, > > +#include "i386-dis-evex-x86-64.h" > + > /* X86_64_VEX_MAP7_F8_L_0_W_0_R_0 */ > { > { Bad_Opcode }, > { PREFIX_TABLE (PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64) }, > }, > - > }; Please can EVEX entries come after VEX ones? > @@ -8979,9 +9055,13 @@ get_valid_dis386 (const struct dis386 *dp, instr_info *ins) > if (!fetch_code (ins->info, ins->codep + 4)) > return &err_opcode; > /* The first byte after 0x62. */ > + if (*ins->codep & 0x8) > + ins->rex2 |= REX_B; > + if (!(*ins->codep & 0x10)) > + ins->rex2 |= REX_R; In patch 1 you check whether REX2 bits are properly consumed. While in principle I agree with re-using ->rex2 here, don't you need to take precautions to not print a random {rex2} (or whichever way it was expressed) when one of these bits ends up not contributing to any operand? > @@ -8994,12 +9074,19 @@ get_valid_dis386 (const struct dis386 *dp, instr_info *ins) > case 0x3: > vex_table_index = EVEX_0F3A; > break; > + case 0x4: > + vex_table_index = EVEX_MAP4; > + ins->evex_type = evex_from_legacy; > + break; > case 0x5: > vex_table_index = EVEX_MAP5; > break; > case 0x6: > vex_table_index = EVEX_MAP6; > break; > + case 0x7: > + vex_table_index = EVEX_MAP7; > + break; > } How is map7 coming into play here? > @@ -9042,12 +9128,31 @@ get_valid_dis386 (const struct dis386 *dp, instr_info *ins) > > if (ins->address_mode != mode_64bit) > { > + if (ins->evex_type != evex_default > + || (ins->rex2 & (REX_B | REX_X))) > + return &bad_opcode; > /* In 16/32-bit mode silently ignore following bits. */ > ins->rex &= ~REX_B; > - ins->vex.r = true; > + ins->rex2 &= ~REX_R; > } > > ins->need_vex = 4; > + > + /* EVEX from legacy instructions require that EVEX.L'L, EVEX.z and the > + lower 2 bits of EVEX.aaa must be 0. > + EVEX from evex instrucions require that EVEX.L'L and the lower 2 bits of > + EVEX.aaa must be 0. */ EVEX from VEX you mean? Also, what about EVEX.z for those? Really the sole difference between the two forms is EVEX.nd. The doc mentions EVEX.l for the from-VEX case, but afaics there's no insn actually having that bit set (which also matches what you say above). > + if (ins->evex_type == evex_from_legacy || ins->evex_type == evex_from_vex) > + { > + if ((*ins->codep & 0x3) != 0 > + || (*ins->codep >> 6 & 0x3) != 0 > + || (ins->evex_type == evex_from_legacy > + && (*ins->codep >> 5 & 0x1) != 0) Please can the shifts be parenthesized agaist the &-s? Albeit - this is perhaps easier to read as just &-s anyway. > + || (ins->evex_type == evex_from_vex > + && !ins->vex.b)) This doesn't look to match any part of the comment. > @@ -9640,6 +9752,19 @@ print_insn (bfd_vma pc, disassemble_info *info, int intel_syntax) > if (ins.last_repnz_prefix >= 0) > ins.all_prefixes[ins.last_repnz_prefix] = 0xf2; > break; > + > + case PREFIX_NP_OR_DATA: > + if (ins.vex.prefix & ~DATA_PREFIX_OPCODE) > + { > + i386_dis_printf (info, dis_style_text, "(bad)"); > + ret = ins.end_codep - priv.the_buffer; > + goto out; > + } > + break; > + > + default: > + break; > + > } Why suddenly a default case? And why an extra blank line below it? > @@ -11242,7 +11367,7 @@ print_register (instr_info *ins, unsigned int reg, unsigned int rexmask, > case b_swap_mode: > if (reg & 4) > USED_REX (0); > - if (ins->rex) > + if (ins->rex || ins->rex2) > names = att_names8rex; > else > names = att_names8; Isn't this already needed in the REX2 patch? > @@ -11460,7 +11585,7 @@ OP_E_memory (instr_info *ins, int bytemode, int sizeflag) > > add += (ins->rex2 & REX_B) ? 16 : 0; > > - if (ins->vex.evex) > + if (ins->vex.evex && ins->evex_type == evex_default) > { > > /* Zeroing-masking is invalid for memory destinations. Set the flag > @@ -11608,6 +11733,13 @@ OP_E_memory (instr_info *ins, int bytemode, int sizeflag) > abort (); > if (ins->vex.evex) > { > + /* S/G EVEX insns require REX_X not to be set. */ > + if (ins->rex2 & REX_X) REX_X in a comment can only mean REX.X. You mean EVEX.X4 though, I think (which internally is latched into the REX_X bit of ->rex2), and that also needs to be set, not clear. Jan