From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 283313864815 for ; Wed, 17 Jan 2024 08:09:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 283313864815 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 283313864815 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::229 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705478960; cv=none; b=UdiVAZqP8ixMzC0fmuz5Z3NmheEAidduxTSc/AdoyzJZfn2G+CUcfWtwdcleO6F7Rz8zDkfuOpGx0GpbE/Nf+4VJNzPOZElgcSEeGmYKz9tZl4WG3mt4htNrRCiSI4zyCMmRh0xo6owJaoCa1VIvNG+xfRi147oAQ2S3tDfqa+c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705478960; c=relaxed/simple; bh=LBbwi3J2+eOlCYIdjHo+DdTvLK8Axdp2QH8VgzQ2CEM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=LqaXc7dggEMHLGvlNcrCqNA/LuUQpHVAPlO0dDzmPrTI8t3K+rNxyhZIhSO8V3WlMyq8f9ykL54rKE4ITjKxZ0qY8ZIkobUwGc6KJ4bN0nHpKldkozFW590RCmyMVpCXkU1HC850ljjTqrGtlpXTxadeUguW/eWI84/CeU/j04I= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2cd8b64a52dso64812961fa.2 for ; Wed, 17 Jan 2024 00:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1705478956; x=1706083756; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3a7rhjJvh7qSG01XQ4SZI5IfzOfdVbcZQF61L6U8ry4=; b=eG/r/S1KY6G6A5q8EmXL3u5N7ZoGNhCuwmdDCt4bCTQVjqOuT+oF70NOM7mZk+M9B4 oO2y9Dw5OE/afP+FxMe3NL+CHikWi7YkwPKwds/jdIcCWKJa0Of9fCoKMrQz+0gBWfbk qyZVsZlMFKhXsdQ/GLHmv6xA1YFtt9SZc6kHmK5VubksqqS3tUlXl+IwLkkIauVK82Ap dwEJu/nkmix2WtfUsV2GV2VShIyocMgATKRAgMvGtUF1AqceXOsJGamAty4QsPG9aYiy YTW97kofoWnpoEDnUyIe3farkGendkKTGSoNZCxufdRkiIBZbti+B8BWLJ+7LV/Zvyyp aveA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705478956; x=1706083756; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3a7rhjJvh7qSG01XQ4SZI5IfzOfdVbcZQF61L6U8ry4=; b=eIjhyUPN2KCgfftp9G8QjA8rwtJpZpYmusTp7q7I5icRxPDzjUXMMsz2L8wUTzFtPW yNGeljJ0qw4ifH5yIrdlaPP00iPznol/fZfNvd/uXp37VPBRAJNdZ7Afyzo/kSqKZJVz jNSqG7RGan9g3kBGkSuUbtXdDGljUt4F/EE6wGuzQzPv9BDUfXuhXLXUwmpry1FOwSHg vworz/7PmJr5jrv+os33vWlEXfAO3SfCP6jmcmVj0lphHFs8EOyQ+8beDtuPJxFn0um1 QOvt4815lWhuhvQ6p7InaYhyHWilxO7JrjHnM6g//eDcDohIRZW5ZHJzhiE02/6zRd5Z I/mg== X-Gm-Message-State: AOJu0Yx2sojgnVYQAx+Li+Ze4DLGvWE6lyt+bmr/GX3S0aZsrUQwOki6 r3wrf+DaikvQOVSrRrAHhVjMlN5SQtWPFuDDQC/s+9mNWw== X-Google-Smtp-Source: AGHT+IHQPI/kS+DQOC3rzdZ9ykTqUb61nQEKOrC5+OMmQZFEWrArQojBYsgj25TWBy7HZCF/NPM7SA== X-Received: by 2002:a2e:a261:0:b0:2cd:c584:9709 with SMTP id k1-20020a2ea261000000b002cdc5849709mr2155014ljm.19.1705478955969; Wed, 17 Jan 2024 00:09:15 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id s27-20020adfa29b000000b00336a2566aa2sm1053120wra.61.2024.01.17.00.09.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Jan 2024 00:09:15 -0800 (PST) Message-ID: Date: Wed, 17 Jan 2024 09:09:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH,V4 10/14] gas: synthesize CFI for hand-written asm To: Indu Bhagat Cc: binutils@sourceware.org References: <20240103071526.3846985-1-indu.bhagat@oracle.com> <20240103071526.3846985-11-indu.bhagat@oracle.com> <0ecd9240-0700-4072-91d4-ccf9bdb56071@suse.com> <055b92ae-b781-41e8-bd34-4ad68bdc5f6f@suse.com> <78b9f98f-2030-4675-af0a-8f47d195711b@oracle.com> <20b71f7f-7c8b-41fd-a85c-6887cc19e5ff@suse.com> <962e43b8-5eea-4f71-9d36-4f95af6a043c@oracle.com> Content-Language: en-US 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: <962e43b8-5eea-4f71-9d36-4f95af6a043c@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3025.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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 17.01.2024 02:20, Indu Bhagat wrote: > On 1/10/24 01:44, Jan Beulich wrote: >> On 10.01.2024 07:10, Indu Bhagat wrote: >>> On 1/9/24 01:30, Jan Beulich wrote: >>>> On 08.01.2024 20:33, Indu Bhagat wrote: >>>>> On 1/5/24 05:58, Jan Beulich wrote: >>>>>> On 03.01.2024 08:15, Indu Bhagat wrote: >>>>>>> +/* Check whether a '66H' prefix accompanies the instruction. >>>>>> With APX 16-bit operand size isn't necessarily represented by a 66h >>>>>> prefix, but perhaps with an "embedded prefix" inside the EVEX one. >>>>>> Therefore both the comment and even more so ... >>>>>> >>>>>>> + The current users of this API are in the handlers for PUSH, POP >>>>>>> + instructions. These instructions affect the stack pointer implicitly: the >>>>>>> + operand size (16, 32, or 64 bits) determines the amount by which the stack >>>>>>> + pointer is decremented (2, 4 or 8). When '66H' prefix is present, the >>>>>>> + instruction has a 16-bit operand. */ >>>>>>> + >>>>>>> +static bool >>>>>>> +ginsn_prefix_66H_p (i386_insn insn) >>>>>> ... the function name would better not allude to just the legacy >>>>>> encoding. Maybe ginsn_opsize_prefix_p()? >>>>>> >>>>> Isnt 66H_p more readable and easier to follow because that's what the >>>>> function is currently checking ? If more scenarios were being handled, >>>>> ginsn_opsize_prefix_p () would fit better. >>>> Well, as said - with APX you can't get away with just 0x66 prefix checking. >>>> That prefix is simply illegal to use with EVEX-encoded insns. >>>> >>> I am using the following in ginsn_opsize_prefix_p (): >>> >>> !(i.prefix[REX_PREFIX] & REX_W) && i.prefix[DATA_PREFIX] == 0x66 >> That addresses one half of my earlier remarks. Note however that elsewhere >> we never check i.prefix[DATA_PREFIX] against being 0x66; we only ever check >> for it being zero or non-zero. I'd like this to remain consistent. >> >> For EVEX-encoded APX insns this isn't going to be sufficient though. See >> respective code in process_suffix(): >> >> /* The DATA PREFIX of EVEX promoted from legacy APX instructions >> needs to be adjusted. */ >> if (i.tm.opcode_space == SPACE_EVEXMAP4) >> { >> gas_assert (!i.tm.opcode_modifier.opcodeprefix); >> i.tm.opcode_modifier.opcodeprefix = PREFIX_0X66; >> } >> else if (!add_prefix (prefix)) >> return 0; >> >> So you'll need to also check for that combination, plus take care of >> avoiding insns where PREFIX_0X66 alters operation, not operand size >> (ADCX being an example). > > [V5 is now committed. I am continuing to work on some of the discussed > pending items from V4.] > > Thanks. So looks like to correctly check for prefix 66H, one needs to > check that: > - !(i.prefix[REX_PREFIX] & REX_W) && i.prefix[DATA_PREFIX] > - (i.tm.opcode_space == SPACE_EVEXMAP4 > && i.tm.opcode_modifier.opcodeprefix == PREFIX_0X66); > - selectively handle the specific ops where PREFIX_0x66 alters > operation. I tried looking around but haven't found a targetted way to > identify such ops. Is there a way ? I'm afraid I'm not aware of any. > Alternatively, since x86_ginsn_new () will be called after > process_suffix (), I wonder if I can update the code to simply check for > i.suffix to be 'w' for reliably detecting the 16-bit ops for all x86 > insns. Is the check on suffix correct and reliable ? Without doing a full audit I'm inclined to say "perhaps". One important thing to consider here is Intel syntax, where (memory) operand size is normally expressed via (here) "word ptr" rather than a suffix. And iirc while suffix derivation (when none was specified) would look at register operands, it wouldn't normally look at memory ones. It feels to me as if it was more robust if you simply set an indicator in SHORT_MNEM_SUFFIX handling within process_suffix(), or if alternatively you broke out the conditional there into a helper function which you then could re-use for your purpose (especially in the latter case beware of the JUMP_BYTE handling, though). Jan