From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 36BF63858287 for ; Fri, 19 Jan 2024 09:13:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 36BF63858287 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 36BF63858287 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::333 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705655596; cv=none; b=ZuDe/ePGK0HF1bqrd3puzEwmVt0rE17x9IAEMkVX3uhcYc6X/cs1bDRozBFg6FBxr/elIn9poSU46JiVTMrS+lNI8s+lSngp/175uNE3rWuKOU8o6ki+/+g0vOUuL0nucnceXvp1KW6EBacN+T2godJvQOrbB+fUYqp7nOqNO3w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705655596; c=relaxed/simple; bh=karxGdkU9DWkKXeGfj/vU0Fvy+Xb8/yDSqUlsXV7iB4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=eavt9+XRfNBDYAJSK9Le/86qwwQ3RNhy/1Sp4m/1qOqwkfFbLpkAXxumgH7lqwwVGN/q0yHt4/eQEryQjNHnGpFRpbp61jXVznXrAj7484TQxK7DqjaZFAGYYHH3UgvG4k7Q25BHx1uWO90dQSYfTLBrQ/0QyZGleduq2C5TAU4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-40e8ff22383so5954805e9.0 for ; Fri, 19 Jan 2024 01:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1705655593; x=1706260393; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=5jOMihfYqaVT8IHjmJYM0iQ0zTzTr83B1GXTkoxyLBw=; b=PFi5OFOTol8mIfJCTKsJCh+SXYS0s9hYveQ9GK0w1VbatoxYz12DNnxnuZfFsdA8sd fGNxnSfpkewy+cshHg5GgLrDzfBjoGyUZNrx/+AyNKvmYLTZ4OmiiHDkBF47xFEmI2Q0 bnhegZElv+hHX1GMqrbRjBa4OdFQPeL+P4sZXWzP1Jy98spIIOXCjsBC2FZd/ttqkPnV M0pMoRcOo2yy7PVvXm0qWnBZcp1RYQfaOg3Ee3955dboJquO/9DZ1T0peh7JYT5kTWz3 kOpvp+7E+2UOFIHIhvNCgF6OWDradm8EffhDMyrymWMa+O4q/BaIxVnBctAR+uCHK5I3 6tfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705655593; x=1706260393; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5jOMihfYqaVT8IHjmJYM0iQ0zTzTr83B1GXTkoxyLBw=; b=WpiVy5yAysRgx54pPiX1qpNj6MPrexFDkIjk8owpEsLBw25FIbDPlBC+rhuaR/ELl9 /l8DXlLFY3eU1XpnH7ZMamt7hAVlbhM89g4Wzu0JetQnAuK6Bq8HEdULODvtvTMnCnsC bb/au4PozhnsH5DqljgU4o71qzD9AdOCSl77sZjGW4LR455AKGldK1XfswEm6pv0zY0L 9u5sgkxoVgPppi54dSKuW/m1nqm+CdM3w8XES0XoAJ5wYqndLz/5wLiKOrDW4AcxM8sC gwORcOOVwImq3NPvPuhfUkxPS/FEiTQgpxEeSOlXkAKY0EnvKlJjqEdYuI0gT3Jb9sud P18w== X-Gm-Message-State: AOJu0YyRkcdyyW+2Gr/1gM0Ks/3bSLra0MlfkWpZuqC/b84sOFJSZShw 1YfLtT6vE5KeW1fyb/fuq1XfPdfvtb9j24PoLN30dYfz865PXBo2JGXtxjF1Yg== X-Google-Smtp-Source: AGHT+IElqERgafEBDuGbyqshJTTLbcbyB97zuY3dX5vXsqLsK/e9h5Zd1U47LUHcHwDiAHNpg0YxgA== X-Received: by 2002:a05:600c:5491:b0:40e:5451:be1a with SMTP id iv17-20020a05600c549100b0040e5451be1amr1136496wmb.82.1705655592993; Fri, 19 Jan 2024 01:13:12 -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 j7-20020a05600c190700b0040e52cac976sm31834034wmq.29.2024.01.19.01.13.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jan 2024 01:13:12 -0800 (PST) Message-ID: <112d6607-3f35-4679-9ba8-d9257d2d20c7@suse.com> Date: Fri, 19 Jan 2024 10:13:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RFC: Formalization of the Intel assembly syntax (PR53929) Content-Language: en-US To: LIU Hao Cc: binutils@sourceware.org, GCC Development References: <95e373fb-24f3-4b10-9ad1-948597ed9d67@suse.com> <40ae7cb2-c094-4594-859d-470e7a7fce49@126.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: <40ae7cb2-c094-4594-859d-470e7a7fce49@126.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 18.01.2024 17:40, LIU Hao wrote: > 在 2024-01-18 20:54, Jan Beulich 写道: >> I'm sorry, but most of your proposal may even be considered for being >> acceptable only if you would gain buy-off from the MASM guys. Anything >> MASM treats as valid ought to be permitted by gas as well (within the >> scope of certain divergence that cannot be changed in gas without >> risking to break people's code). It could probably be considered to >> introduce a "strict" mode of Intel syntax, following some / most of >> what you propose; making this the default cannot be an option. > > Thanks for your reply. > > I have attached the Markdown source for that page, modified a few hours ago. I am planning to make > some updates according to your advice tomorrow. Just to mention it: Attaching is in no way better than providing a link, commenting-wise. > And yes, I am proposing a 'strict' mode, however not for humans, only for compilers. > > My first message references a GCC bug report, where the problematic symbol `bx` comes from C source. > I have been aware of the `/APP` and `/NO_APP` markers in generated assembly, so I suspect that GAS > should be able to tell which parts are generated from a compiler and which parts are composed by > hand. The proposed strict mode may apply only to the output from GCC, which are much more likely to > contain bad symbols, but are also more controllable on the GCC side. > > I believe that skillful people who write x86 assembly have known that `offset`, `shr`, `si` etc. are > 'bad' names for symbols. Therefore, it's like an issue there. > > >> Commenting on individual aspects of your proposal is a little difficult, >> as you didn't provide the proposal inline (and hence it cannot be easily >> used as context in a reply). But to mention the imo worst aspect: >> Declaring >> >> mov eax, [rcx] >> >> as invalid is a no-go. > > I agree. I am considering to declare the lack of a symbol as a special case. Well, I took this as the simplest example. But clearly there should never be a need for an assembly programmer to needlessly write "dword ptr" or alike, when operand size is unambiguous. Limiting "strict mode" to compiler output would take away concerns in this regard (as machine generated assembly has no issue with uniformly adding such redundant specifiers, much like in AT&T mode suffixes would typically be emitted even when not needed). But I see a severe issue with your aim at confining strict mode to compiler generated code only: In inline assembly (see your mentioning of APP / NO_APP above) you still potentially reference C symbols. So the ambiguities don't disappear in APP / NO_APP regions. >> I also don't see how this would be related to the >> issue at hand. What's in the square brackets may as well be a symbol >> name, so requiring the "mode specifier" doesn't disambiguate things at >> all. > > If someone declares a variable called `rcx` in C, it has be translated to > > mov eax, DWORD PTR rcx # `movl rcx, %eax` > > instead of > > mov eax, DWORD PTR [rcx] # `movl (%rcx), %eax` And an array happening to be indexed by rcx would then result in mov eax, DWORD PTR rcx[rcx] # `movl rcx(%rcx), %eax` ? That's going to be confusing at best. I think this whole issue needs taking care of differently, and iirc I did already suggest an alternative in one of the bugzilla entries involved: Potentially ambiguous names (which to a compiler may mean: all symbol names) ought to simply be quoted, and it ought to be specified that quoted symbols are never registers. Iirc this will require gas changes, yes, but it'll address all ambiguities afaict. Jan