From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on2059.outbound.protection.outlook.com [40.107.13.59]) by sourceware.org (Postfix) with ESMTPS id E00C03858D37 for ; Tue, 28 Nov 2023 08:34:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E00C03858D37 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 E00C03858D37 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.13.59 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701160489; cv=pass; b=hEBJGvdMmUuuQJp63IYUpWBTLH+UX1gCs2/sjgnO9HBSYFPcgILqd2Y1kDCCKmXB0yzgvBtIJfjwX4FOCDhdEN16ZZBYkGFSVliRHCrxA2AdSH/zMXDB0kB2g1sNcXzya311DyfT/P+HxMFZUdbng1AeUfLQOWX/8ESD0hZ4caM= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701160489; c=relaxed/simple; bh=aerVh/MCvUeN2FuTR8NpGfAqSIUctqDdQ4YetMzKUPY=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=xA3Xa+RsXJ8egSnxDC1looIgAacdqM5O/WOs3OctrE9uHq4hyZvBNCyLOrZy7ZRp4+UmJSbD+XK1fmyNW43h+Pvpm9CT9S6Y9JKA56uZ9kejtkx6tX50IkYfXSb6VSknM7v7f4C2PZiwT03lUkfPGWgpsBs1rB7pU62oRYKzEUE= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MKlYp9K341TnBP/Std1a8rN6yBrxwr+9TqHuyacSQHNS6p/T8adETdORPZf4nqIVYXf3aSkV9sX+uncJ3WweIbw1ydrRN40M2uYZRZhaXa0d+q9q4QUldida2dIU8dz66xhrhnunYB8X0alvrMHWUBaAm/Nepm5fRcFIYjZo8be4a674uMTU/ApJ9Daz3YplljQXv+mukvDLczE9aVeCti4i+BDsiJgLJjGDkRfYjaFL4+n/xg4KChKBx2vkzvClrE3P/1z8Jfvcc/Wg3MOMsiMBDSvOhGv7VF+CMV6INC9WbwB8+uR/bA5LEL00cPPmD2OHZlBXR3hxF/tlCowrRA== 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=FiyL11ceJLd60WRa63k0pZYVkp0MoQm8N1RiynTjJEc=; b=L/7+VzhqPOl1rIkGbL16Rvxl+X7tc1+QrXT1nHFuqQhkPdohI6oQBtfa/f4gpsuN6SuNd9pre9+HXSGRzdHaYPpjiMBNyBxAFGHVOyuv2DQjV1EaAg+wegxK0U5FS8eKm6sSnNCWp5d+48D2gEhF+BTfaGjT4Urh3E4w1mGgWGftKFquqZIQKhh5pnjVu6AYPMTSevodA6JMR117At97j0u1V7gZ64pX/5ed4DXa2jevAgw2nmbDWYMWQ5FH/Gshf4iqIinOJfJ8qynCtENhxIlTG+VKiTJ0A57EP+9FXAMVt22NAmyat0hgr48sexuyl65C8+SZ8MduAa4qauU3/Q== 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=FiyL11ceJLd60WRa63k0pZYVkp0MoQm8N1RiynTjJEc=; b=YN5bqtCIpEGNZBjJHUWNi1PeT2ao9f1ToOhCZNccW4i2XEXztUOWoztTGyKd9exz6d8OrxhurEMP6/t8K1fNvC/wqL/bLF2NZZ3U/J5qI97Qtj4elxJJKhA2vaPhs4tNa7Yu0pIoQbNWLFNtqFs/PQWP+Q11hetFMw04dlDltms2E/SDRIEIJFQZZ8j8dxo2V7e/EQimDMuoy4H5dDUGUw3JyC0nR4N0VXIxBvJzSFPus6gpfhhXYtyGbqjsckkezilZX5xfF7RAIZNO65WvBBS54BAvbFyYqcU2dWDCGozMstoSLCPMwjhLrGmkXXLzu8/hHogORumCyx3+qxpb7Q== 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 DUZPR04MB9897.eurprd04.prod.outlook.com (2603:10a6:10:4ad::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7046.21; Tue, 28 Nov 2023 08:34:43 +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.7046.015; Tue, 28 Nov 2023 08:34:43 +0000 Message-ID: <8858e7c5-97b2-4ec4-bd21-6371f92493bb@suse.com> Date: Tue, 28 Nov 2023 09:34:41 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Support APX PUSHP/POPP Content-Language: en-US To: "Cui, Lili" Cc: "Lu, Hongjiu" , "ccoutant@gmail.com" , "binutils@sourceware.org" References: <20231127123106.3600817-1-lili.cui@intel.com> <4f005f5c-52c4-4631-bee7-6396add7c5df@suse.com> <3abc4b98-59ab-48b4-8690-99d00e55ad1f@suse.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR4P281CA0352.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:f4::6) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|DUZPR04MB9897:EE_ X-MS-Office365-Filtering-Correlation-Id: 7ab1111b-e1f1-44d2-effe-08dbefecdebc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QPqM6pkbhTQrlJ0Z6zST7qXZN2YGLNQMUpXcurXYas0VoQ7+4JZdY+OPwpqs2Cg81tQWv6H+CtBb9RwTvzdzwIRE36feGg5UQG+DZbX1PxG/lXZOaqNo0ft+hXNyys+2y34SX3pinxvcCNfvIjoLGGQ+iJ5A+WIW4AMQT8qX0enX6W2ElUmzTaYJAGwhEFsKp09tv8JvMIb5tS2WjSQmbbCo/USNxW7VbVjCzdSqsc49vvsiEXlPQ6WM7nzqrHM3y5WPcUtnjKlzjw/3ZfKVkXAC3T5jbBK7sddXhPazyqEeN/MJz9j5aLsbOy+a2a8vo5TRuVyoalAqHEA+1Zr4NVfiUZs1CTnCmicv3VmwddWRPbEn63/BBL+NQ+Wr3ZgixaAdeon2xDy3+1FnVeUFIRa/SNp17KtYTprQZS0rpTfjgmx+qtEBQctXqyaWjOvkYYzNPmrgY9bZ1RDwxOpUVvnKbi6h9Kd4+CMjxbJSWouIH6eVEp3ztwai/dYZoxykspnRRQYeivpCd4HPwwQtZ4uCUsr+4hR+arNnNxjpYqTYan7HQQFFCdGLCVVDy6YvqbJXERN1fh9X6uUOFhrF9utbEUX7DRYy9iZmZvAjZTuMRPU8G8jfL8b0wsEi2jSB6qEM53/YgvGHsaRM/oEPhA== 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)(39860400002)(366004)(396003)(376002)(136003)(230922051799003)(1800799012)(64100799003)(186009)(451199024)(38100700002)(31686004)(8936002)(316002)(4326008)(66946007)(6486002)(41300700001)(53546011)(86362001)(31696002)(6506007)(66476007)(5660300002)(66556008)(6512007)(6916009)(54906003)(478600001)(2906002)(2616005)(8676002)(66899024)(36756003)(26005)(83380400001)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WkRuUDRwOUxwNWRiWjZWYXpUbEZ2elZ5N3Btc3RIRVFGQy9WbGw5aDE2QU1S?= =?utf-8?B?UC9WVEFVWU5TaUJQeG9nanA4L0FhbVFPMmY4Y2QrV2xNV0IraTdmU1p3ZHpH?= =?utf-8?B?SmFTWW0xWWkza3FkR2xTbENxd0g4dGpMUDI0Q0R2akQ3Rmd6TklENE9ZOERa?= =?utf-8?B?NTFpeXg4WjFxZFo2SGMzZUszT2FYSXFzZzlmY0Vhb3hVZXpWM2ZvRHJ0NGVH?= =?utf-8?B?ek4yRkR1L0g1Z0ZkMTlXL0pxaGhxWHh0aTdwTnEyUUd2clBoeFRvSHNPdGcz?= =?utf-8?B?TE4weU9iWmpLQkFNWE1qVmRQYkpERFdMZ3ppUlcxRHRxcjFiNFRqZzI0V1Z2?= =?utf-8?B?VkFtMHlMbVpqdzJ6LzYzbnpxS255T1NpaEp4UUY5blQzZXh3R2VaWE51dmVy?= =?utf-8?B?UTl2QWJQYk1vS2J0Z29nZ1RpWU9PTlorelB6aG5CNUpGTWY1YmhRZXBpUmRw?= =?utf-8?B?SCtqL1FKSWtWK1BZWHhScWdNSWljbGpSZFJQdFFWemZ4K1lxeFdqUWRraHB5?= =?utf-8?B?YWFRQXF0eWVHZi8rRFFReFBpNHMvcUExWTRyTE81cm9wcU16a01SY2d4TlZZ?= =?utf-8?B?WFU3WEt0Y2VseitvOFdkTTVReVR1M1dVWFlOUzZjMWEzMTFHaHRlYWlmZXla?= =?utf-8?B?cW1JWC9PL1pJYmhoVk9HNnZkZTVqdGxWNmlua2xTVVpCN0o1VE9MU3g5cHd3?= =?utf-8?B?dERoZG9jcXo1clZMcFRWT1NZRlk0Tzk2bGkrdGdCOU1nRGlWVS9YMm9ZVEZ5?= =?utf-8?B?ajlIN3VITVpHMUduYlNRUHdteHRINThBVUN0YXdCMHg1NUxkeHM5R05mamVs?= =?utf-8?B?V21hNThmMmFuUnJiYjY5cVJXSHVPZStyc3ltRGhpdjIvS0RJTFU5TnZNS3FP?= =?utf-8?B?MU1zZGpwV1kveXpxL0FrTmFjSEY2V3ZOQ255c3hwNDkzcndpcCtBYTRJeUlH?= =?utf-8?B?dEIzUTZTdGJuQW5WUXRKUmt2OFIyMG0zL3lmbis1YkZqOVNxYjhTWldIUVFj?= =?utf-8?B?QjJ3U0RBYW1yTEc1VG1zVHZqQ2hEOWo1V3BVZFdVZXZIN0dkdEl4TDI2ZkJQ?= =?utf-8?B?N3ZKazU1VEU5QU40WTh1UXpUTUV1aHp2TFRGVlc0Rk5vemVoZGJDd1Z4QW1I?= =?utf-8?B?QzNydFRUc0xsVHQxTVJxa2tLeENnRExCbE1MYlRxaFNnbVNQNkY4eHdTUk83?= =?utf-8?B?SjNrVWMySE5RK016c1lKeGxaazlYdmFrUVZsL0lRZDlYMnk0WXhCaXFkclR0?= =?utf-8?B?SWdiVFJROVVHYVIvVzhyVld2T0FkYmg5MGxMYzB4WXpSalFPUEczODVUaStM?= =?utf-8?B?d2FXb1JxbmZQelE4WTdHeVdTVFkxcndUV0IrYS9TVDRmWDVDRE5EY3E3VUxM?= =?utf-8?B?TGZDMGU0cnUwNUNqMytTeE0rTTlodTc1MldUcncyUlNzUi8vNVkxYktjK202?= =?utf-8?B?QjdaRXBHd2RKQXdMdWpWd2tHUlc3dTVMcnpXbjB6M2lsYnozcGNZd1RUSWtL?= =?utf-8?B?TlZjeDRhNHk5ZXl2MHRxM3I4OXlTRTlBczZBNVdSeDdRNEduMTBTTGxiYnph?= =?utf-8?B?amNmQU9yOVVSS0Y4MldsWkhXUWU4dUlTeVZ5YjB2OS9jTnphazdhaUZyV1BD?= =?utf-8?B?Zk1ubWRkdE5tUWdsOWtSTmdoK3dCQmZKTmlBbkt3QTJZVWFpMDhRWE9maDVS?= =?utf-8?B?ay9LT0hSQnJqUkx0dE1pUXo2Y3NVT1dkUlBvSHBFKzQrWVprYm0yckxJSm9X?= =?utf-8?B?VFowaWM3b1I1dGd1enpQZm4ycUVhMmNkQ1hKODE2VTJqdGl4MENpbzFSRVFB?= =?utf-8?B?TmhCN2xnZHdKazNKQklHU3FsSUNqY2g3U0lXdXhyUC9zMHk0YXpkZUFxMHV4?= =?utf-8?B?cmdIL3pXWk1BU21Dc053R0F3TndIYklTTmh0cEpOaU5vcmVFV1QrL2xOdmxS?= =?utf-8?B?eTNrRWdWU3FlYmtlNHZFNWZCVEt2RDI2d1dQUFpRMnBTM2xjN2o0WFlLRE02?= =?utf-8?B?WWFqWDZvTHVsNlQ5b1NSQmRnN0NaZHZ0VGE5aFBNS3hxdUpzNnltMkZKcURt?= =?utf-8?B?ZEZYQ25sdTBHTU8zOUIzZjN6U2dGdm9lcmp1djlZZThBWnFpMWhuSWNhYURx?= =?utf-8?Q?doTIl4AuSuOe4idOyu2kT2ZHd?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7ab1111b-e1f1-44d2-effe-08dbefecdebc X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2023 08:34:43.2311 (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: r9ZlbA+ZxdFvoasS4I9qiL33I6qPv3GCm9KVJMoFxqjd87JB0PVAtfZj5hX0a/sJAmWW3ZDVZsqfTYqHCeSA+A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DUZPR04MB9897 X-Spam-Status: No, score=-3032.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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 28.11.2023 03:32, Cui, Lili wrote: >>>>> --- a/opcodes/i386-dis.c >>>>> +++ b/opcodes/i386-dis.c >>>>> @@ -1931,23 +1931,23 @@ static const struct dis386 dis386[] = { >>>>> { "dec{S|}", { RMeSI }, 0 }, >>>>> { "dec{S|}", { RMeDI }, 0 }, >>>>> /* 50 */ >>>>> - { "push{!P|}", { RMrAX }, 0 }, >>>>> - { "push{!P|}", { RMrCX }, 0 }, >>>>> - { "push{!P|}", { RMrDX }, 0 }, >>>>> - { "push{!P|}", { RMrBX }, 0 }, >>>>> - { "push{!P|}", { RMrSP }, 0 }, >>>>> - { "push{!P|}", { RMrBP }, 0 }, >>>>> - { "push{!P|}", { RMrSI }, 0 }, >>>>> - { "push{!P|}", { RMrDI }, 0 }, >>>>> + { "push!P", { RMrAX }, 0 }, >>>>> + { "push!P", { RMrCX }, 0 }, >>>>> + { "push!P", { RMrDX }, 0 }, >>>>> + { "push!P", { RMrBX }, 0 }, >>>>> + { "push!P", { RMrSP }, 0 }, >>>>> + { "push!P", { RMrBP }, 0 }, >>>>> + { "push!P", { RMrSI }, 0 }, >>>>> + { "push!P", { RMrDI }, 0 }, >>>>> /* 58 */ >>>>> - { "pop{!P|}", { RMrAX }, 0 }, >>>>> - { "pop{!P|}", { RMrCX }, 0 }, >>>>> - { "pop{!P|}", { RMrDX }, 0 }, >>>>> - { "pop{!P|}", { RMrBX }, 0 }, >>>>> - { "pop{!P|}", { RMrSP }, 0 }, >>>>> - { "pop{!P|}", { RMrBP }, 0 }, >>>>> - { "pop{!P|}", { RMrSI }, 0 }, >>>>> - { "pop{!P|}", { RMrDI }, 0 }, >>>>> + { "pop!P", { RMrAX }, 0 }, >>>>> + { "pop!P", { RMrCX }, 0 }, >>>>> + { "pop!P", { RMrDX }, 0 }, >>>>> + { "pop!P", { RMrBX }, 0 }, >>>>> + { "pop!P", { RMrSP }, 0 }, >>>>> + { "pop!P", { RMrBP }, 0 }, >>>>> + { "pop!P", { RMrSI }, 0 }, >>>>> + { "pop!P", { RMrDI }, 0 }, >>>>> /* 60 */ >>>>> { X86_64_TABLE (X86_64_60) }, >>>>> { X86_64_TABLE (X86_64_61) }, >>>>> @@ -10621,6 +10621,19 @@ putop (instr_info *ins, const char >>>> *in_template, int sizeflag) >>>>> case 'P': >>>>> if (l == 0) >>>>> { >>>>> + /* For pushp and popp, do not print {rex2} for them. */ >>>>> + if (ins->address_mode == mode_64bit && !cond >>>> >>>> I don't think the mode_64bit check is needed here, as without that >>>> REX.W cannot possibly be set (nor can a REX2 prefix be present). >>> >>> Done. >>> >>>> >>>>> + && ins->last_rex2_prefix >= 0 && (ins->rex & REX_W)) >>>>> + { >>>>> + *ins->obufp++ = 'p'; >>>>> + ins->rex2 |= 16; >>>> >>>> Please no new use of magic constants. Have a #define with a suitable >>>> name, and use that here. Also I think the comment you have ahead of >>>> the if() actually belongs here? >>>> >>> >>> How about " #define IMPLICIT_REX2 16", PUSHP/POPP can share it with >> JMPABS. >> >> But what's implicit about the REX2 prefix here? > > PUSHP/POPP requires rex2.w ==1 and we don't want to print {rex2} for it. JMPABS has the same need, so I want to define a common macro for them, or NO_NEED_PRINT_REX2? Yes, we want a shared constant here (as much as we want a shared way of dealing with the need to emit REX2 in the assembler). Still, the naming wants to fit not only the goal (to suppress the printing of {rex2}), but also where the bit is actually stored (in ->rex2). Therefore its name wants to fit with the other names used for bits in that field. Which (to me) first of all means it wants to start with REX_ (or REX2_). REX_SPECIAL or REX2_SPECIAL might be an option, but might also be too generic (i.e. becoming an issue down the road). But I think this should give you an idea ... Then again, why is this constant needed for PUSHP/POPP, which have REX2.W set anyway, and hence that bit alone (when properly marked as consumed) should already allow to omit {rex2}. The question of adding a new constant (and how to suitably name it) would then be fully constrained to the JMPABS patch (for now, i.e. until such time that a 2nd insn appears which requires an otherwise empty REX2 prefix). >>>>> --- a/opcodes/i386-opc.tbl >>>>> +++ b/opcodes/i386-opc.tbl >>>>> @@ -225,6 +225,7 @@ push, 0x68, i186&No64, >>>>> DefaultSize|No_bSuf|No_sSuf|No_qSuf, { Imm16|Imm32 } push, 0x6, >>>> No64, >>>>> DefaultSize|No_bSuf|No_sSuf|No_qSuf, { SReg } // In 64bit mode, the >>>> operand size is implicitly 64bit. >>>>> push, 0x50, x64, No_bSuf|No_lSuf|No_sSuf|NoRex64, { Reg16|Reg64 } >>>>> +pushp, 0x50, APX_F, No_bSuf|No_lSuf|No_sSuf|Rex2, {Reg64 } >>>> >>>> Since Reg16 isn't allowed, you also want No_wSuf here (and below). >>>> Note also the missing blank after the opening figure brace. >>>> >>> >>> Done. >>> >>>> The new Rex2 attribute is not only wasteful (it can easily be a new >>>> enumerator used with OperandConstraint), but also misleading. We >>>> don't just need REX2 here, but we need it with REX2.W set. Even if >>>> from the tc-i386.c changes it looks as if that was happening >>>> implicitly (presumably due to the absence of NoRex64), naming still needs >> to properly reflect the purpose. >>>> >>> >>> You are right, rex2.w is set in process_suffix, since there is no NoRex64. >>> >>> How about Rex2W? >>> if (i.tm.opcode_modifier.rex2w) >>> { >>> i.rex2_encoding = true; >>> i.rex |= REX_W; // add NoRex64 back, and set REX_W here. >>> } >>> >>> >>> Or just add a special judgment? >>> >>> if (t->mnem_off == MN_pushp || t->mnem_off == MN_popp) { >>> i.rex2_encoding = true; >>> i.rex |= REX_W; // add NoRex64 back, and set REX_W here. >>> } >> >> I'd prefer the latter over a new attribute (albeit once again with the comment >> actually matching code), and perhaps I view the latter equal to my earlier >> suggestion. >> > > Ok, put them in process_operands, there's already a special handler here to change the prefix. > > diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c > index 0dde2a9ad44..2f2b1b04d10 100644 > --- a/gas/config/tc-i386.c > +++ b/gas/config/tc-i386.c > @@ -8715,6 +8715,13 @@ process_operands (void) > i.tm.operands++; > } > > + /* PUSHP/POPP requires rex2.w == 1. */ > + if (i.tm.mnem_off == MN_pushp || i.tm.mnem_off == MN_popp) > + { > + i.rex2_encoding = true; > + i.rex |= REX_W; > + } Well, I'm sorry for not considering JMPABS earlier on, but with that also needing dealing with, I think I view my alternative suggestion as preferable. That'll scale better when also considering that down the road further such insns may appear. Whether it's actually OperandConstraint that we leverage here is secondary (it's not ideal because there's nothing operand related here). I'd be perfectly okay with some other attribute being suitably overloaded, whereas I continue to think that introducing new attributes should preferably be limited to either cases where more than just two or three templates use them or cases where otherwise it's impossible to avoid ambiguities. From earlier changes of mine the underlying reason ought to be pretty clear: Each new attribute consumes storage, and with thousands of templates growth of storage requirements should be balanced with how frequently an attribute is actually going to have a non-zero value. For example, with is_evex_encoding() gone a brief inspection suggests that it might be possible to overload Masking (or maybe Broadcast): They're applicable to EVEX templates only, and the class of insns we're discussing here is never going to be EVEX (or VEX). IOW not much different from the overloading of StaticRounding. Such an overload may then well be named Rex2 (as you had it, and considering its intended use also for JMPABS, plus taking into consideration that REX2.W will be set simply because of the absence of NoRex64). The other issue I have with your approach is that you again (ab)use i.rex2_encoding: As expressed before, that's representing {rex2}, i.e. a weak request (aka hint). Whereas the two insns here _require_ a REX2 prefix. Doing so may end up being tolerable, but would require extra justification and/or commenting. Finally putting the logic in process_operands() is also misleading: There's no processing of operands here. Pre-existing abuse of the function (as you appear to indicate exists, albeit I didn't go check) is not really a good excuse, I'm afraid. Jan