From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM0-obe.outbound.protection.outlook.com (mail-am0eur02on2060.outbound.protection.outlook.com [40.107.247.60]) by sourceware.org (Postfix) with ESMTPS id 85ABB3858C2F for ; Fri, 10 Nov 2023 12:35:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 85ABB3858C2F 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 85ABB3858C2F Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.247.60 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699619759; cv=pass; b=Y9j2sZTL/oFLXDfiWkqu6c0AkwUt7f+ia8r1KEufT+hjnE16lLrunIng3cG5AnVRiWLkiJDHbGKI+Is8MdnKUO2FwhLrzIQAwjIjuLXjilFzmZ3jSYzyT37d8+3dtlyHSeWhO4fzELgtZNetoge6huL62OwwVRS0DFLWPNv62JY= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699619759; c=relaxed/simple; bh=Zy7DkJaHth1gSZNuNGqNg3D72pPkPsc6l9ohS8xF60M=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=LvYek/QwIohrq5MTR/JJ/YGFrZa1Sr1ir6JdclqVSC0sszBiZBosm+9keAtREVIZ+2MCtuC1+LOTHxpoWHDBuuhuHwAmXJhOLdqkkAEx8qlFkRT3lD7LstHrRt4goSJuxLm5/TdMjX1tOBHOKCe+o5TlbSYVwcgVNi+NI12smxs= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V9UicGasLQ8KpkYo5dgTTnONXtYtaQFAtwlbHOYCmb/QTswEWyJhjMd2xhVVJ38XS2X8lXMwBzm/BVDQiSV0yD1/d7onDMUcPBc2bs1F8SAfyCL6rFVDOr+Rj90npoquzR7MIiRs6iH2GqM6xzGoHT7J9Vd9jhqhL5P9cxKXFFVubknU96ApAy090yZLzS8CAsAzD1991vQOopan0VswscnU7jNQq/46WYjI0hHOM0HlGrb2Qn/KT2g+IjvyeL+iitiXlAuytS6G077U5rUQknyMPrwFgRFhmSENJwFxmNbTLR3NW/iS5HhG4kz5djnzwukTswO1tHgN37JaG5Uh3A== 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=+Z4GSOEKwWa5DpxfvmtgDcvFvVBVA8zZXtiU147b+bo=; b=an1s4pgt2I5h5ZIALMihNyTkFQNQNARt9R4JWYaXLiIZJ/V3wcJD6Elz4CFAvIeo7upQocKQPYJ1m6+7MME6gsNbom1kuhHdAddh7Dk9aqMIBjD9XIcyUoHjU3moDS2EfUONeTMpuUsxk2BvVPl/SG9cJvhmy9lTqyci/kMeOpERTHrQbaKwryNchZssD5rCzoiApaLO1+fUAjL6enhYNu1e/9ZUPsfaMgVQbPAn+m0nEDs7rJFpCBoUZ8KXqJtQipdDEeWHA0cRADn41m36BHrF5zHFqxnAfdvsNjCo0+z6N6r9zjY69frn5bWtar6vwJiq9XuFE1H9XP3DOkPPpw== 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=+Z4GSOEKwWa5DpxfvmtgDcvFvVBVA8zZXtiU147b+bo=; b=Ku0+DnaEDxsiWLNU/EPMRS4fVK4Yj4cjD2MQCF8YiGWLJG4U8urxqGBSZTeGy6nHmlS8mI9DS32Q2+LRBRwKMuKghGDY0DsLm3zccxrCM0a5iwuycvS5rJC+GdutwFzepkbSiYISk8uxKrxuvlGto5M9+pG/9LYvN76pWIj8irlNEm5IhFActa33RsdZL4CLTy1ckhRcErD3x+JWwwHxsEzhpfZWYZiwPcPJNMxUTFLnzqiY+pJxkowj6wV8tbV8u/w5WHDgdbwWMpvZ2qvBrVGyqTypjc++nUXMsIEfSM+MJrx9MC0bSm5+2X06PwSJ9GS1RsZBHWzdLihmuSHWVQ== 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 DBBPR04MB8026.eurprd04.prod.outlook.com (2603:10a6:10:1ed::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.10; Fri, 10 Nov 2023 12:35:54 +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.7002.010; Fri, 10 Nov 2023 12:35:54 +0000 Message-ID: Date: Fri, 10 Nov 2023 13:35:51 +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> <968ed07c-65bf-c7de-e213-0b9b5f3fbefd@suse.com> <182c6fcb-4efe-7de2-394c-830e8d7f17c2@suse.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR0P281CA0090.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1e::15) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|DBBPR04MB8026:EE_ X-MS-Office365-Filtering-Correlation-Id: d1e2ae39-e9bb-4872-de81-08dbe1e99486 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Nmcij8LpXZ99dFOLKo1m4tnu9XXaSB1e9ak2uKK3EWj3Pl7uklM1cKbVQFqfpYYByxD7jj61Vm9YqiimrC+57zi5n/EeP5DBPFYApFLApzWAOff+vq9yNjh8t1dqwxHJhHq12dQ4jhPKMZqy+sJTErGPluFerGbONGaA9qr1SOuoy5clrKIJmvDyRNQqAYl/pdVT7Mzt0bdCkJt8M1mb8mF7XekiLKACw9Gc2LJFhWsneq7/zS8QtmqecAU/DQL8NqTjPLdCt2DWJ/KZFU0xFPtqpkH95i5sShMs+KjyTw0CbRj8blOsoHnd9usaVoyemo+GLxcYXWmDq9f87zxxtvBQQKXe144T4QJAZzuXKef3ynKd2BD0wWzTJuhDdKOTJKIbto2AU4k3ZUsulBmUNqW6Znr9/hEwiLNfFf2NbvRtWZl1a7SLgEKBss+vxrHxNBuOb+jw+YYW80AUMcmLmh7i6sm8UDCEXE5yxahZOOnrb8bFUCnU7hzlQO9qhCrU1osc2Da0lYFbvpVll+prgvkUWV7uBhgEI7h1EZD+ffwYh/Ov7ezoG3oO7xJBdoUs4ipzxpT/ynK/nZlOMfcYhwAf1WxDuQbZc/juDgCUc08KFa4ucxEoyAEuONLRClM0YOsvrv3yCJzHKxHhfBimnw== 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)(366004)(136003)(396003)(39860400002)(376002)(346002)(230922051799003)(451199024)(186009)(64100799003)(1800799009)(2616005)(38100700002)(31686004)(6512007)(6506007)(83380400001)(26005)(53546011)(6486002)(478600001)(6666004)(66946007)(66556008)(54906003)(66476007)(6916009)(316002)(41300700001)(36756003)(8936002)(8676002)(4326008)(2906002)(86362001)(31696002)(5660300002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z1hxVmNvRUFNMk1HNjJPZTZMU2c5ZCtFOC9uWDMvZmNZaDJWVlBVOVFGdmVn?= =?utf-8?B?Z2dLdnhobElsSjN3bFhHaC9CZ1FweHBjOVJ1ZmZDUEN5VDd1MVR5d2czRUdl?= =?utf-8?B?THNUeUFENjV6RVhDazM1R1UzTk5JZHlqcDNIdEI4a3dKYlBkS0hEbGNIellu?= =?utf-8?B?Z3daRkRqOFBlMWlXRzhaNVhtc2ZqTjllS0E2V2JWSlk2Nllsell2c016Wmts?= =?utf-8?B?SVNTaGlpbGdpUURNZDBoaGZnUHNKMFdNMjFPaUo4ZnlISFBPQk10bXoyWkdE?= =?utf-8?B?akhiUjNyTGN2NXdORDZUV0owUS9DWU9DYWI1c0I3a3ZKT0JEeW02RGJGaXpp?= =?utf-8?B?REM2YUk0SjNzSi9rWXlxNUNReFJ1cXJ2bWI4QzNxemlyQXpsaEcrQUtuMXg5?= =?utf-8?B?cFdHWWlBWmR2SElPY1kzZU9GKzArYjI2L281QzRoUDNPR2RrbGkzbWtXVW9z?= =?utf-8?B?MzdNV25FRmJabnZNdnovaHhsc1YwTm9zaHI5dVlkSUJkK2Vpa1Q1UUhCT05B?= =?utf-8?B?OUdjMW9VRTZ6SVNjWWZha2tRU1JpbUpOYm1OZlNUdkF0UkFEb3N3NmpNT0Rk?= =?utf-8?B?djhRRGNORGdzKzVBZWxkNW4xWlNJUkNGTXFWUjZ1T21adnI0NTJ3a0cwa2JC?= =?utf-8?B?Y2IxNlhKWmVMZHRJQXR0UGdteEpJVTloNzJzdWZQUTR2dXM3UEJzTDhDQ00z?= =?utf-8?B?VDdKdWQ5bnFEV3ZSV3JVUkV6ak5LcEFqRnZIbU01dkoyb1ZSMUhHN3pCL2JU?= =?utf-8?B?MjJiMUlXUnZpVE1mQzMyakw0Y2p2NS9tK2hOb1pvbzNWSFpLQWF5ekd0WXJZ?= =?utf-8?B?WW1QMXBJUXhQQlB3OE5wM2dlaUVxa3o0VCtqNXIzU3VWbUNidUhaODloV011?= =?utf-8?B?WjdjVk1oZmdRemxQbkFSZXpIL2NaelJ6SFhPZWtMRlAyT3JydllrZU5DbDVD?= =?utf-8?B?RGh4dGdmYjFyWkJmYUFVNWFJTUtraC91RjBjaGxZTDN3RDR5bjV0Y1ZlN2w0?= =?utf-8?B?YmdIN0pzZTZmanFzQ2ticmZmcHdWaEpPbTFUcFcxc1NHa1dkTXB2YXh4Yk02?= =?utf-8?B?S3VaSHVDQkxVbGNmbE1rbExPZmRKY01LbDhoS3Z0VGJlQkw0Z2ZuR0tOb0RJ?= =?utf-8?B?RHU1RitOTE9JRS9YQjZUbml2QnlEZ2ZtOUZ0UEJrKzBmaDJFYzdBanp2ejFh?= =?utf-8?B?WDdGZjJ6VVBwMDNyS3doaVpYOVYvbTV3bXc3V3RDb09TS25rZE56TVZiZTB6?= =?utf-8?B?QkdsUEZqMmxlMlBzc00vTjBCTWxnNVpqNDVKd3M5eFJRQXpnYUhSUXUyd3Jl?= =?utf-8?B?VjN4Tzh4SG44T3M1SnoydGkxUlpRL2lzeVk2OTJ4VGJETFMydjJrVkhPRTNK?= =?utf-8?B?ZWg3STVKaUxiQmQ2aTRING8xNnhWVG9BK1cyTzRyamZvWis2SG1KaFJXcVRD?= =?utf-8?B?QUJmdWd4TEdDN0JNKzB0TUN1c0wzSFY3QlVuZWxzdU42THVpd25aVFRBMDZt?= =?utf-8?B?dG5FT0tjUkdzWFQ5NXhIclhUM0FBRlpaTEl5TFV3TklKalhlMTdtSklSSE1n?= =?utf-8?B?UzF6UU9LWDVlaWpnQ1VsT2hGVDdFd3ZQZmVNTEF5YmJlWG40akJZZjFKaUlI?= =?utf-8?B?MlRGS3NVSjZEalJjallXK1BkZ0M3dlljcDkwRGtZckNUbVd6WGsrNHUxajhm?= =?utf-8?B?R2lkRWVlV3dPL09jaGhseG8vS1VCVVlzK0M3YmFZbnBkR1llc0ZEZ0JUWTdM?= =?utf-8?B?OHBZaVpUOTViOE4yYWp4Yks5Y3lnYzQxcjkvb0xjclZsUGY0Qk15RmRkdVRF?= =?utf-8?B?Q1d4eCt6TE85bElRMEl0N0FqN1VXdlZXNGtldml4eWRjRjBvZWZEUWt3Nmls?= =?utf-8?B?bmZSRTcvNERFQXcwcVg5YTFHamIrUWhvZklaWkc3eUJUeFJ5cStwRHlEOGZp?= =?utf-8?B?eUlpMFNNamhQS1dISHl5emxWR2NvSDE1RUJlVFV3RW5HNCt3Y000SWVhcXQw?= =?utf-8?B?Mm1Nb2VhY2tld3Rtam5ZeTkzazdkbEdTSWRaVmtmVXJ0T2dGU0JBb1E3emNE?= =?utf-8?B?QTVmdXNXTkw0NTRiUFpCT3l3NVVrMm80TXFMdjE2NW5lVWZHbHh5WEpiODZi?= =?utf-8?Q?2UBkMxZSyHFam/8IlxDMn5RW9?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: d1e2ae39-e9bb-4872-de81-08dbe1e99486 X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2023 12:35:54.0567 (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: qjLOoIXgxq3llYUsU5eAN8LWS9VzwUW1ZEFAbKPWESTbWiZvlW8ZAnIlB1CnMXyyLjH4WBpI5aFb7FR9tnOVNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR04MB8026 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 10.11.2023 13:05, Cui, Lili wrote: > > >> -----Original Message----- >> From: Jan Beulich >> Sent: Friday, November 10, 2023 5:57 PM >> To: Cui, Lili >> Cc: Lu, Hongjiu ; ccoutant@gmail.com; >> binutils@sourceware.org >> Subject: Re: [PATCH 1/8] Support APX GPR32 with rex2 prefix >> >> On 10.11.2023 10:47, Cui, Lili wrote: >>>> Subject: Re: [PATCH 1/8] Support APX GPR32 with rex2 prefix >>>> >>>> On 10.11.2023 08:11, Cui, Lili wrote: >>>>>> Subject: Re: [PATCH 1/8] Support APX GPR32 with rex2 prefix >>>>>> >>>>>> 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). >>>>>> >>>>> >>>>> I'm confused here, for d5 00 0f when it fetches the next byte after >>>>> 0f it will >>>> find there is no byte there and then go to fetch_error_out and then >>>> it will return from print_insn and I don't have a chance to do >>>> anything for it. It cannot reach dis386_twobyte[]. >>>> >>>> But why would it even try to fetch the next byte? 0f already is the >>>> major opcode byte in this case. Fetching more can only mean either >>>> there's an entry in dis386[] specifying operands, or there's an >>>> attempt to index dis386_twobyte[]. Since dis386[] has Bad_Opcode at >>>> that slot, I conclude that what you say confirms my suspicion that >>>> dis386_twobyte[] is (attempted to >>>> be) used here. >>>> >>> >>> I don't know how to identify that 0f is the last byte of the binary, >> >> That's entirely irrelevant here. I gave the byte sequence d5 00 0f just as the >> minimal one required to make my point. My original concern equally applies >> to e.g. d5 00 0f 01 00, which may not use dis386_twobyte[0x01]. >> > Aha, I got you. Changed the code to > > /* REX2.M in rex2 prefix represents map0 or map1. */ > - if (*ins.codep == 0x0f || (ins.rex2 & REX2_M)) > + if ((*ins.codep == 0x0f && ins.last_rex2_prefix < 0) || (ins.rex2 & REX2_M)) Would you mind considering if (ins.last_rex2_prefix < 0 ? *ins.codep == 0x0f : (ins.rex2 & REX2_M)) as an alternative? Jan