From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 49A22388C020 for ; Tue, 22 Sep 2020 16:08:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 49A22388C020 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 01517AC6E; Tue, 22 Sep 2020 16:09:21 +0000 (UTC) Subject: Re: Enable support to Intel Key locker instructions. To: "Cui, Lili" Cc: "binutils@sourceware.org" , "H. J. Lu" References: From: Jan Beulich Message-ID: Date: Tue, 22 Sep 2020 18:08:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3033.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 16:08:46 -0000 On 22.09.2020 10:53, Cui, Lili wrote: >> On 21.09.2020 05:25, Cui, Lili wrote: >>> --- a/opcodes/i386-dis.c >>> +++ b/opcodes/i386-dis.c >>> @@ -691,6 +691,7 @@ enum >>> REG_0F18, >>> REG_0F1C_P_0_MOD_0, >>> REG_0F1E_P_1_MOD_3, >>> + REG_0F38D8_PREFIX_1, >>> REG_0F71, >>> REG_0F72, >>> REG_0F73, >> >> This addition wants to go further down. While not immediately visible here, ... >> >>> @@ -797,12 +798,18 @@ enum >>> MOD_VEX_0F385E_X86_64_P_1_W_0, >>> MOD_VEX_0F385E_X86_64_P_2_W_0, >>> MOD_VEX_0F385E_X86_64_P_3_W_0, >>> + MOD_0F38DC_PREFIX_1, >>> + MOD_0F38DD_PREFIX_1, >>> + MOD_0F38DE_PREFIX_1, >>> + MOD_0F38DF_PREFIX_1, >>> MOD_0F38F5, >>> MOD_0F38F6_PREFIX_0, >>> MOD_0F38F8_PREFIX_1, >>> MOD_0F38F8_PREFIX_2, >>> MOD_0F38F8_PREFIX_3, >>> MOD_0F38F9, >>> + MOD_0F38FA_PREFIX_1, >>> + MOD_0F38FB_PREFIX_1, >>> MOD_62_32BIT, >>> MOD_C4_32BIT, >>> MOD_C5_32BIT, >> >> ... in this table you'll notice that MOD_0F38* all go together, and _later_ >> there's a MOD_VEX_0F38* group. I notice that recent additions (of yours?) also >> already violate this sorting model - please may I ask for this to corrected as well? >> The more outliers we have there, the more difficult will it be to maintain this >> code. > > Thank you reviewing my patch. I put MOD_VEX_0F38* together. Imo this should be a separate change, not merged into here. >>> @@ -8236,6 +8319,16 @@ static const struct dis386 mod_table[][2] = { >>> /* MOD_0F38F9 */ >>> { "movdiri", { Edq, Gdq }, PREFIX_OPCODE }, >>> }, >>> + { >>> + /* MOD_0F38FA_PREFIX_1 */ >>> + { Bad_Opcode }, >>> + { "encodekey128", { Gd, Ed }, PREFIX_OPCODE }, }, { >>> + /* MOD_0F38FB_PREFIX_1 */ >>> + { Bad_Opcode }, >>> + { "encodekey256", { Gd, Ed }, PREFIX_OPCODE }, }, >> >> The use of Gd and Ed will, afaict, lead to REX.W decoding as 64-bit register >> operands, which according to doc and gas implementation looks wrong. > > I didn't find the code we use REX.W to determine the size of register with Gd and Ed. > Could you help elaborate on it? It seems that Gd and Ed are correct. My mistake - I mixed up Gd/Ed with Gv/Ev, sorry. >>> +Unspecified|BaseIndex } aesdecwide256kl, 1, 0xf30f38d8, 0x3, 3, >>> +CpuWIDEKL, >>> +Modrm|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, >> { >>> +Unspecified|BaseIndex } >> >> ... these four need special treatment in output_insn()'s setting of >> GNU_PROPERTY_X86_FEATURE_2_XMM, due to the lack of explicit RegXMM >> operands. >> > Added it. If I was making a change like this, I'm pretty sure H.J. would ask me to also add test cases for it. Jan