From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by sourceware.org (Postfix) with ESMTPS id A67673858D28 for ; Thu, 18 Aug 2022 14:51:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A67673858D28 Received: by mail-qt1-x82e.google.com with SMTP id cr9so1248009qtb.13 for ; Thu, 18 Aug 2022 07:51:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=vhGFeKRYCla0JRG1zdgBPR9YDNp4leooz4drkvsOEiQ=; b=TUqpr9AR/qg8IGkOPBSA8E85vGteAwdrVjFyUH7oiEN0g+Lwg9NOEoNIeK+DmjvaYH hpgr+gNtihazLvsN9S45DTVd2epWh7oyknjF9xGKCZit0WuvNBTGBDoSrESDxiTQOLOV s8o967GAN5vPaAkt1gAbpx8jZl/v359EdR56eAoc1n3GBBEc3WGfYbyCPFPUPAPFeVzM kHa2XpLAQ+gfWuzxxQaBSetCpTCW5gLVCiqDN0YcVHf0bZve9zel02xnY3av3cMe2xaV wU0F/w1Dyivs40QrFIAaPVXF6xGL1JZ0hcWToBglWf6tXS77Gy5DSLR6OKZPs3diuE3q PKMQ== X-Gm-Message-State: ACgBeo3NwYSoLkgSSb2vqoK2ufuji3K5fYbutYhKHOTxS/ioxlI1pvZ0 lJtWCxf+HdTP0N2xxQfWM2I81x2wD1c+qVHzibo= X-Google-Smtp-Source: AA6agR4a1aLmnU81iKZ3wluje7mVjZIZSa5j+sceJKhtk3tUOHdZzpBbkTAoNNm5SF4xXbSdtong60lZLYSoPYAZ1N4= X-Received: by 2002:ac8:7c56:0:b0:344:24c1:60ff with SMTP id o22-20020ac87c56000000b0034424c160ffmr2889738qtv.437.1660834310923; Thu, 18 Aug 2022 07:51:50 -0700 (PDT) MIME-Version: 1.0 References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> <0ac5121d-5318-b065-57c6-b94085ed6b23@suse.com> In-Reply-To: From: "H.J. Lu" Date: Thu, 18 Aug 2022 07:51:15 -0700 Message-ID: Subject: Re: [PATCH 4/7] x86: improve match_template()'s diagnostics To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2022 14:51:53 -0000 On Wed, Aug 17, 2022 at 11:14 PM Jan Beulich wrote: > > On 17.08.2022 22:24, H.J. Lu wrote: > > On Tue, Aug 16, 2022 at 12:32 AM Jan Beulich wrote: > >> > >> At the example of > >> > >> extractps $0, %xmm0, %xmm0 > >> insertps $0, %xmm0, %eax > >> > >> (both having respectively the same mistake of using the wrong kind of > >> destination register) it is easy to see that current behavior is far > >> from ideal: The former results in "unsupported instruction" for 32-bit > >> code simply because the 2nd template we have is a Cpu64 one. Instead we > >> should aim at emitting the "best" possible error, which will typically > >> be the one where we passed the largest number of checks. Generalize the > >> original "specific_error" approach by making it apply to the entire > >> matching loop, utilizing that line numbers increase as we pass further > >> checks. > >> --- > >> As to the inval-tls testcase: Why is KMOV special? Are e.g. VMOV or > >> other vector insns (legacy or EVEX-encoded) any different? Shouldn't the > >> use of the respective reloc types be limited to _exactly_ the insns they > >> are intended to be used with? Furthermore having this check in > >> match_template() is unhelpful, as the resulting diagnostic isn't aiding > >> in understanding what's wrong. Template matching should be left alone > >> here, and the issue be diagnosed later, say directly in md_assemble() > >> (alongside the various further consistency checks there) or in > >> process_operands(). > > > > GCC may generate invalid TLS code sequences with KMOV, not other > > instructions. We want to catch them by assembler. It is easier to disallow > > the invalid instructions. > > I did actually check both the discussion and gcc code in question, and I > was not able to prove that it could have done so only for KMOV. And yes, > I agree with disallowing the invalid instructions. The question is why > we do so only for a limited and inconsistent subset. So far, linker only sees it with KMOV. Linker will issue an error if other instructions are used. > In addition you don't say anything regarding the point in time when we > diagnose this, the placement of which - as said - looks sub-optimal to me. > Improvement is welcome. -- H.J.