From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2055.outbound.protection.outlook.com [40.107.20.55]) by sourceware.org (Postfix) with ESMTPS id 436943858D1E for ; Thu, 9 Nov 2023 15:23:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 436943858D1E 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 436943858D1E Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.20.55 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699543387; cv=pass; b=YAqrXNAez5CzVkxnOPTwWHX+96i6Jh30fcXPWNDWCUVGaDq0Si2f2yQKD14xafFIEurM3U2UUfTCJVrpagGWNbfBj4mwGFAfekbez9rVtZzQZOKIzABZfd6b0jrVSYwq7E34iyitds372YXRtDqiAjRH4iLlhQmW+XPcdleC71s= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699543387; c=relaxed/simple; bh=Rn4OII8dZMYR7/nHWiTD+jVe6S9bZh1OsMQi5UZSC7k=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=SZ5ThuTJeAj4FwlwyA7q1QWdVmRXYzDJXUGakj/a8CSYEoBw3GaYHTWCEBvutJpmzQxP4fSAhbpxFwfulxqOpfmVQuLCb/SsMCiwqC0OheRIK0Yhr/5AI2Sqajj7JF+OD+FbomddD60YToqFgn+g4jN9TeZeGLDiqrM5Bpj0sUw= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZZCFntvDc79OlsgHYNK8O6L5VnPfa6kPa5z9u28lscYILDKc02bp/lP5YO9PUnjP4sbHM1oVQi5mxihi/uy20yGBj9TKfZcGmNm+zqZJ28qfDnNj13u9Q7Ho7feuxz1xRFPfjfYjHMBWMmkdxUnojJzc83x/H1DSyeQgGfG6+gdFmk0wDdyRqqsJQjPmHea0RyJeLheNBgswO0vv1KlieD8OL0f17nLyW+afeSazTbPLAheJj0mud4POEPLAshtzyLePoLE5vYtCVQim5ux0LkSpJdI2w+V5PEsvnDnmXqcwYXwA+Nkx3JVfjLQqH6FxXajPziVXCYmVH0+MrJoaWA== 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=IXmJkuZm+2x9DLJ6z2WiDDVEIX8O9zyw+wCQRA46Nk8=; b=jGVZD+tqfSsJyZwIz514lQgzUqWjCmij8FOcYZ175kNgsjBuh7uShirSg4Z8HU46eS8Y7adOo2Fjn8GvROJJqnLpYHsv1r2X8BSp2TIYrTa+oG4ggzcvLJzjXhwPcjgygjdfJSpSDLHtGrcuXgeGXdfu/WNl3pAX1DP6Uo/wfQ32Psd2YM10s533O7ALGLUa/su5O2xGS57LtD5VwbbM0qLQcOojEY8MP5Ify+LbXvqiTAEzJlSNE/bufWjPNvGZEMAcxDqYXm1ve9AUFZGbGwlEP3v8WqK8vx/FMGyDVLFweCsQieOS3StWwdyXizmNlCWCeuybmXM3qVDMtYJRoA== 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=IXmJkuZm+2x9DLJ6z2WiDDVEIX8O9zyw+wCQRA46Nk8=; b=w47t1XCI4SBzHl9aw2OdLl9rEWs0xngGdmfOi6KcHKMo31CXpOglon4N9Vp4VUm0UkpJeRousrOyGuoapTuuyL35QUC04ILMWKrzy+04UowfoNOacc8KCeu3LEb2rc8Jqhsj1PdGr0oGUk+jAxVQo55pxO4hVz9fCQnbN40g7ONhJtQuD7fwcumCrU8f8+TXt6+KIHcFIgwGrIbbRmyUDWYFLbyAgX7ll7z2Cbxpi5/AwI9X1HCXkD29kV9AckEfYsvMAlnRaa1xv6cGOtXZ9FUXKl5P3jrLyOx83KgmyFbSKZZlJS9k15HRl4EQ51ukQgtiok+dG7wqBqt+DD7i+Q== 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 AS8PR04MB8404.eurprd04.prod.outlook.com (2603:10a6:20b:3f8::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.7; Thu, 9 Nov 2023 15:23:01 +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.018; Thu, 9 Nov 2023 15:23:01 +0000 Message-ID: Date: Thu, 9 Nov 2023 16:22:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH 1/8] Support APX GPR32 with rex2 prefix Content-Language: en-US To: "Cui, Lili" Cc: "Lu, Hongjiu" , "ccoutant@gmail.com" , "binutils@sourceware.org" References: <20231102112911.2372810-1-lili.cui@intel.com> <20231102112911.2372810-2-lili.cui@intel.com> <5807de3c-c509-69df-cdaf-e334ab26bc5f@suse.com> <8d748339-0505-ecfe-762d-a476e0c019ad@suse.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR4P281CA0109.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:bb::13) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|AS8PR04MB8404:EE_ X-MS-Office365-Filtering-Correlation-Id: 80ec6389-4110-4548-7a48-08dbe137c2a5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: L0I4pJHzJioRvedPVdzkfklxrcQjyvizMhRHS9AklSj4C6xMrbEDDzUbDEBmFs2bQG7xNzca/7NeGOVYRV5QEOufSDBf2mx+juqZ8Fs8zFYbI8WL9urGRIjwNcz0Uzx4jK1VhJZ9NwjVdnJOOrfb73uhhQOwao4m79maVzkeF0MeH8Mq5W1A7/2piPQISRLKj/T539WFaxHBCmmFEq8WUsbmZbNOb2SY2wt5k9wWvpb+scy/qDebl98XO0WNRQANXCTg+dr9OTZHOoNi4HIKEM/tRYS5KDdFnKb66KcisltkryoPztZx6CYwxJeHLIO3UQCikr6t9UOw1qbx4mRcjLzl7Etv/9anFPPwB4omrpNPguEeM5T9y0qpkKtuK5LG7NsMC3+WaN5nsJYX5fmw1Y70EMrKlHF1OTNDBrBA+zKZmHLoCsX+kayxqJ9oV+qyNmOATnYwqzgKwKfy3+WR0XhPzUgVycHKYfLFJpeojmZFixIDcl7zwgq/3wZRhlO9gz20jBB9BdoyNvDcjFOZ5a28TTONORPatAS92O+uOL06v8Xf2ujfgKD/ICc771a9lR9a97ce2dmquhfscPzhsEb+wIAdCJza6kDJoIoJHXxw2JoWSKnFrNx21ZI1BYB1ppiaNmT6DiXFFyN3ouXFLQ== 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)(136003)(39860400002)(376002)(346002)(396003)(366004)(230922051799003)(451199024)(64100799003)(186009)(1800799009)(6506007)(83380400001)(8676002)(8936002)(4326008)(6512007)(2616005)(6486002)(31686004)(53546011)(6666004)(478600001)(316002)(54906003)(66556008)(66476007)(66946007)(6916009)(26005)(5660300002)(38100700002)(41300700001)(66899024)(2906002)(36756003)(86362001)(31696002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bzBudEN2eWdQUXdHVzFzSk4vTDZiZjBKbG5sR2pWbmxqMzJSalFpZFpLR0NY?= =?utf-8?B?eVpDSStwbXFFTThzRmNxRktwK2hiZlpTTUprVE81cE9obDVlbjdQbzRKV2pp?= =?utf-8?B?K2VlN0VtU1dleHZHeFBIZyt6WUw0N0xvTUd5a1U2djRTUWtzdkVHM2llQXdu?= =?utf-8?B?ZTVZWDRsbG4zYlZJejFtZlc2bHY4LzBSaUdVQ0w2aTlBeGtZUTRwNlgwUW03?= =?utf-8?B?c29FRGFsYTNpUnhwalh5aFY4c2lUNloyVmhoL0lTN3poQW9kMzBzbzNqMHNX?= =?utf-8?B?QXVVR0JyemQ2YkpLZzZCRlkrMjdWYXF1TWtVVUhqbXBpckJnUFp5aVlLUkNo?= =?utf-8?B?LzZpN0pFSU1vbWJXZmVzb2Z3YldRNDBxcVpqRkpmMTY4SUxKMFFaeWxxbHFo?= =?utf-8?B?aXNTSlVWR3hsWld5WUJHVVVEU2l1WXZoL0RIMnF3elRqV0dRWHhpWFp3WVJq?= =?utf-8?B?SjVHVXZPTFlKZndYTXljamFWcjNLQk5MeFIrc2tKbFpVVjNXN0tWZThPajZ1?= =?utf-8?B?SVRKOVlpdnpLckQxZ2V1WlN5c1ZtOWd3NXJWNy9yZWU5OE9UalBGVmtYNTEv?= =?utf-8?B?RVNWeGJ2WjI2VE9OOU5nR0dlSmg2NTJ1dG9XdGxGNEdWMlpZeDFxalRWOWx1?= =?utf-8?B?bW00cVM3SjBvbFlWeWMzTDBmcGZuZm5pa1pCdXdmcTNncDhJdkUvU0twUWRa?= =?utf-8?B?TWFHeXoxN1o3Vmg2ZGE2Q3ljbFpUVVVnYXBiUG1JaTVEZWRGMlBvWlRtN25K?= =?utf-8?B?K0E2MmxEalU2UGoySitqTDhXV1Y3M1VJRXk4a3FJdTZBcjRFZmtia2FtVVNz?= =?utf-8?B?OVRiL3BKOUhTUUVBZy9LTFBKNmpTWXZVaHRTWFJFbXBqRy9NUmVCNGppbDFC?= =?utf-8?B?SFYwK0FQT0lxOE9VNFNtVUxDM0tPSlRBNk9BNitWQWNGYzFtMmRiMCt3aFNl?= =?utf-8?B?UTd6UGVKYmRJVGRMVTZKaUcvc2xBczczMGNqRGo1VTIycUVTajZoMzRYcmhp?= =?utf-8?B?NEZ4L1BHMGYwbzE5OERCcVl0UnNBUEJtdENhTzhwSHdrdWJEbVBYcVVhWnph?= =?utf-8?B?VzNnd1BKNDZkZ29JWU1jbDdCODcxdVNsVHRHZzFhcGh5ejlhVXBMd2pSTFA1?= =?utf-8?B?RllFcnFTZ2FzMXZPVGxJelc2K0xUR1l3SHZVZW9lQUNXL2p2UC9sbGtWbUFj?= =?utf-8?B?bWhENTUzb2MvVTc5MGdmZWVmcDB3OUo1NzBaYUZoNU1GNHd5bHNsdWpNQ3pv?= =?utf-8?B?WjZ6NXFRSUkzYnJ0M3hlbnBoSWU2R0x2VW54bENmMDNlbGJEU1VKL3BleDA0?= =?utf-8?B?VmFlM2VQb1BldE0wNmtEODRYRy9JTk1WY1RpVmRFM3hMS3NVMkt6RkpiU1Vv?= =?utf-8?B?d29HQm9PRGVCZ01qaSswQ2VObHpwNkNGNGNhaFNqZ1FWNHA1c0h5MHd5UDNR?= =?utf-8?B?K0tSQkhlb1dkU1Fyc040VXpvM1dDL1l0MFFhT0Z6UVJIc1NIdktRY2FKTTZB?= =?utf-8?B?bndyTkkvQ1BISldNZU9Rek9wMVhhZVIrb2drSjZ5Uy92VHFNNkJIQ1JjVm1V?= =?utf-8?B?N0ZlUy9hKzNjdWp0TldDTmcvQmNodm1sdWV5TXhzQVVjc0pNVFplZHlYclNs?= =?utf-8?B?MVVJSDV0SFZFOHJtaE52TEhhWkt0cnJ1UmNpUnQzc0k3TmNJRC9jaldCTWFl?= =?utf-8?B?Yk9rRkVsMVVaZmpLNTJsYnAxN2c0bExRalhJSWVpSHdrVHhtL2xjeWxqKy92?= =?utf-8?B?MUxnYjJDaVVuenV5azRJeW5oczNCd1V1SHJjWmZqZldKZFBSeU5rSUN1WWtG?= =?utf-8?B?REswV0R4K1NCcU54Rzg3WkVPelZjOXltWTB4R0cyTEUxNWV6VW9yS3QyVEV4?= =?utf-8?B?YkI2LzBaWjFnZEZCQldiRWFFdUV4dVkrM2p4TWZ2V0ZUT0dUVk9jZStpaWUz?= =?utf-8?B?YjdwYUdVL1MzdXZWUVBpaitUckh0c25wR0h0cmtESkNOeis2VkZMV0ljS2tq?= =?utf-8?B?VzZ1dVVPUnFiaDlDcStvWFUrNlM0NWlDWFNjeWFHcStjWTcvakxUMjFoczI2?= =?utf-8?B?SmUrS1R4RW5vNnFTbDFGRmpYdWRoNkl6YkMxa21EWUhlbmlFQWdGZVp4dldT?= =?utf-8?Q?icIIYEuzdKNNqYdrfiWZwUoli?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80ec6389-4110-4548-7a48-08dbe137c2a5 X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2023 15:23:00.9416 (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: 6NFChWi1xpktG/UgneCVJo0vC5mxYzSNQTfgCYztrWSUF0688Y9B7PJWoEowvjXag9Of2c+jRVYFuoDGJ3SIrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB8404 X-Spam-Status: No, score=-3028.1 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 09.11.2023 14:27, Cui, Lili wrote: >>>> Also is this, ... >>>> >>>>> { >>>>> unsigned char threebyte; >>>>> >>>>> - ins.codep++; >>>>> - if (!fetch_code (info, ins.codep + 1)) >>>>> - goto fetch_error_out; >>>>> + if (!ins.rex2) >>>>> + { >>>>> + ins.codep++; >>>>> + if (!fetch_code (info, ins.codep + 1)) >>>>> + goto fetch_error_out; >>>>> + } >>>>> threebyte = *ins.codep; >>>>> dp = &dis386_twobyte[threebyte]; >>>>> ins.need_modrm = twobyte_has_modrm[threebyte]; >>>> >>>> ... all the way to here, really correct for d5 00 0f? >>>> >>> >>> I think the 0f here must indicate that it is the first byte of the legacy map1 >> instruction, meaning legacy map0 does not have 0f opcode. If this instruction >> has a rex2 prefix, rex2.w must be 1 and should be d5 80. If a bad binary does >> appear, our original code also has the same issue. >>> >>> static const struct dis386 dis386[] = { ... >>> / * 0f */ >>> { Bad_Opcode }, /* 0x0f extended opcode escape */ >> >> No, this entry simply will never be used, because of how decoding is done. >> My comment was about what's going to happen if you encounter the d5 00 0f >> byte sequence. That's _not_ an indication to use map1 for decoding, nor to >> read another opcode byte. In this case the table entry you quote above will >> need to come into play, not any entry from dis386_twobyte[]. (As long as both >> are Bad_Opcode the difference may not even be noticeable, but it would be a >> latent trap for someone to fall into down the road.) >> > > > /* REX2.M in rex2 prefix represents map0 or map1. */ > if (*ins.codep == 0x0f || (ins.rex2 & REX2_M)) > { > unsigned char threebyte; > > if (!ins.rex2) > { > ins.codep++; > if (!fetch_code (info, ins.codep + 1)) > goto fetch_error_out; ---> When there are no bytes after 0f, it will jump to fetch error, but no error will be reported. > } > threebyte = *ins.codep; > dp = &dis386_twobyte[threebyte]; > ins.need_modrm = twobyte_has_modrm[threebyte]; > ins.codep++; > } > > For d5 00 0f > Decode to: > 0: d5 rex2 > 1: 00 0f add %cl,(%rdi) But this would better have d5 00 0f all on the first line (it definitely needs to have d5 00 on the same line, as the bytes belong together), as opposed to ... > For 40 0f > Decode to: > 0: 40 rex > 1: 0f .byte 0xf ... this where there truly is a known missing byte before we could proceed further. (It's still a little questionable to print REX separately in this case, but that's the way the binutils disassembler has always worked.) Yet to restate - to see what I mean, you'd need to populate at least one of the two 0f slots in the mentioned arrays. What I'm suspecting from the code as this patch version has it is that d5 00 0f would wrongly descend into dis386_twobyte[]. Yet you can tell that from it correctly using dis386[] only if the two 0f slots of these arrays are meaningfully different (or by actually looking at things in e.g. a debugger). >>>>> @@ -9513,6 +9572,13 @@ print_insn (bfd_vma pc, disassemble_info >>>>> *info, >>>> int intel_syntax) >>>>> && !ins.need_vex && ins.last_rex_prefix >= 0) >>>>> ins.all_prefixes[ins.last_rex_prefix] = 0; >>>>> >>>>> + /* Check if the REX2 prefix is used. */ >>>>> + if (ins.last_rex2_prefix >= 0 >>>>> + && ((((ins.rex2 & 0x7) ^ (ins.rex2_used & 0x7)) == 0 >>>>> + && (ins.rex2 & 0x7)) >>>> >>>> DYM ((ins.rex2 & 7) & ~(ins.rex2_used & 7)) != 0 >>>> >>> >>> Here's an example of a negative scenario, when ins.rex2 == 1 and >> ins.rex2_used == 1, we want to clear last_rex2_prefix, because it has egpr and >> we don't want to add {rex2} to it. >> >> Well, that would be dealt with as well by the simpler code I suggested, >> wouldn't it? >> > > No, for d510 , ((ins.rex2 & 7) & ~(ins.rex2_used & 7)) == 0. Anyway, I want to delete them. I don't see any point in it at all. Hmm, I guess I'm confused. How would you present unconsumed REX2.{R,X,B}{3,4} then? >>>>> @@ -11086,8 +11155,11 @@ print_register (instr_info *ins, unsigned >>>>> int >>>> reg, unsigned int rexmask, >>>>> ins->illegal_masking = true; >>>>> >>>>> USED_REX (rexmask); >>>>> + USED_REX2 (rexmask); >>>> >>>> Do both really need tracking separately? Whatever consumes REX.B will >>>> also consume REX2.B4, an so on. >>>> >>> I was confused here, I think we only need to print {rex2} for the upper 4 bits >> == *000, which means egpr is not used and we need to use {rex2} to >> distinguish it from legacy encoding. maybe we don’t need ((ins.rex2 & 0x7) ^ >> (ins.rex2_used & 0x7)) == 0, and nor USED_REX2 (rexmask). I intend to delete >> them. >>> >>> + /* Check if the REX2 prefix is used. */ >>> + if (ins.last_rex2_prefix >= 0 >>> + && ((((ins.rex2 & 0x7) ^ (ins.rex2_used & 0x7)) == 0 >>> + && (ins.rex2 & 0x7)) >> >> But that's the same you had before. I'm afraid I don't see what you're trying >> to tell me. >> > After removing " ((ins.rex2 & 0x7) ^ (ins.rex2_used & 0x7)) == 0 ", the code changes to > > + /* Check if the REX2 prefix is used. */ > + if (ins.last_rex2_prefix >= 0 && (ins.rex2 & 0x7)) > > When it is true, decode will not print the {rex2} for this insn. Yet ins.rex2 having any of the low 3 bits set says nothing about whether every one of these was consumed while processing operands / suffixes. You need to consult .rex{,2}_used; my earlier point was merely that you don't need a separate .rex2_used; the bits in .rex_used are all you require to get this right (as a consumer of, say, REX.X / REX2.X3 is also a consumer of REX2.X4; leaving aside EVEX encoded insns for the moment). Jan