From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by sourceware.org (Postfix) with ESMTPS id 6ED473858C5F for ; Thu, 8 Feb 2024 11:32:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6ED473858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6ED473858C5F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707391934; cv=none; b=Hi1x4TEocSHR+NfdIuqw0y/neQHCn1LEs8CPBhxRBDttjCYUvQYN2eTlChPHWiYw5d75o7lNI4UAEFharyFnN29JPryIQAYfcBZjx0Fa8F8HgkAeh3lSHGu2eViMJBOzOWtSGQQoUr8SFUloCfW/jsFD6hDdRcZkIPHg7454Guk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707391934; c=relaxed/simple; bh=0FcKEvmNWJYC201hv9GwTw+zuyfgGlaigfOi52PqdN8=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=savSYS/70l5ys2LBnpiabNQGy1PgxHE4EIuCs38K/koi/iw/lK55RF4hxlKzUHuCgP+zgOE4AYH5fm+aPFOZ9sJFzU1oBMXJwvvYYhsace/VEhEg9E6x1h+3cyOj5PxcLfYFmN7KGwj9idNf9lYKYO3D8fQBQLrHUGi8bWbsVWM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-604aab67616so3453477b3.2 for ; Thu, 08 Feb 2024 03:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707391932; x=1707996732; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=J49GhWp5nqVZFkEoPAHIagGDzLydZGx98BPbERk+MeU=; b=D/Gi0pXvKBMCVqXn+/EZ+Ylbvq2qan7n/QPaos3SRro20aRyilHExomfwOKkMMQNvT pdXPnmzy5xqE5t/6FoHYuKvWFEpK/AzwVLoJAusbh/KxLmE/Ts7MVh9d8TeSSKlF6mEL nEVCtmM7mkulDTrKqgxAlzoKaCaC6U6imAnoAYSjSTnRuenv4DnvnbKR3Sq4Id338XJv /YJX30h2C8A8dndH8dDbyDnI0JJSjjsXNX0oYaRg++S0Cxen/Xbv6nRQ6S5J0u8oreje ds0VaGxBnTkrAK0YCvky19Rck6NLsiipls4eT5qG+on10hgYToipslGiA10dVxVbE0DZ 4eBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707391932; x=1707996732; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=J49GhWp5nqVZFkEoPAHIagGDzLydZGx98BPbERk+MeU=; b=Jsf/H+RkPhPhjUIm9dJkTSUC0yaXYpYpIC0WyzydlP2w8sJqOYX4mMd/VOyDGf3zvT UjK1T9ZEeiZO5JDORS5dy60tVp9LllMLhyVK7HeJ2/gPpUI4O+Il/bQmQIR2cJPhf98U uZt4rum+wo0AJ2sBD7MV64R6BGF9zSvmeDVbeTZdPk3e/a16a5fz7Gxo5noQfSFOUbaw LDhuZi2AHeM74hN/mlp/K1n5sZ6X067y/gI27hPm9UMcSgJpDebIA6wm3BGXnPFP6VA9 mOv6kd8rdHohxa882/IIOzfaG80S2MBWAax5Onfc6EMc3Ej7XNa/v09Y9uAKoPRGCdxC y52A== X-Gm-Message-State: AOJu0YxWW8yJRiSvsBITbFixdXdfzyNHx4SMINzwu17VbTVFwFXYWwpg 2tmdd739aXMedcu7PQqrCr5vsieuCQYJVwdNqQTpcKunPmWrqjp9EovUIRkkyP8iRC7ym3D/cGp 9q3IfVZLp8mGhlcp7OnXTVT+tNQ4= X-Google-Smtp-Source: AGHT+IE0VdaC7YahlyzmgGwGFeDxORiyQOdBPB468xC0hF4fcpvCMUeejg1zQxF1hBr8XqDbbNYF8i5WzbD33STOTGc= X-Received: by 2002:a25:361c:0:b0:dc6:18d0:95b0 with SMTP id d28-20020a25361c000000b00dc618d095b0mr8213094yba.8.1707391930201; Thu, 08 Feb 2024 03:32:10 -0800 (PST) MIME-Version: 1.0 References: <20240205200028.219844-1-hjl.tools@gmail.com> <4b1c3da8-d218-460b-89e6-6844096ed393@suse.com> <533a896f-8eec-b73b-cb18-26240ad822fc@suse.de> <8059bdee-392a-b9cd-41d5-8dea538c957c@suse.de> <1b053bdf-6b6d-4d8f-a172-4dc5f503dc58@suse.com> In-Reply-To: <1b053bdf-6b6d-4d8f-a172-4dc5f503dc58@suse.com> From: "H.J. Lu" Date: Thu, 8 Feb 2024 03:31:34 -0800 Message-ID: Subject: Re: [PATCH] x86: Warn .insn instruction with length > 15 bytes To: Jan Beulich Cc: "Cui, Lili" , "binutils@sourceware.org" , Michael Matz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3014.8 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 List-Id: On Thu, Feb 8, 2024 at 12:18=E2=80=AFAM Jan Beulich wro= te: > > On 08.02.2024 07:41, Cui, Lili wrote: > >>> When a warning is given, a decodable instruction should still be > >>> generated. > >> > >> A software library can decode such instruction just fine. A human as = well. > >> > >>> Assembler shouldn't generate something which can't be decoded by > >>> default. > >> > >> That's the important words: "by default". Here's the documentation fo= r > >> as_bad and as_warn: > >> > >> as_bad() is used to mark errors that result in what we > >> presume to be a useless object file. Say, we ignored > >> something that might have been vital. > >> ... > >> > >> as_warn() is used when we have an error from which we > >> have a plausible error recovery. eg, masking the top > >> bits of a constant that is longer than will fit in the > >> destination. In this case we will continue to assemble > >> the source, although we may have made a bad assumption, > >> and we will produce an object file and return normal exit > >> status (ie, no error). > >> ... > >> > >> It's obvious to me that just continuing to assemble the over-long inst= ruction is > >> a "plausible error recovery". It's even more plausible than "masking = the top > >> bits of a constant". Certainly an object file containing a byte seque= nce > >> correspending to the overlong instruction is not "useless". > >> > >> I understand why you want to give an error by default, even though I d= isagree > >> with even that (in my book only a warning is justified). But ruling o= ut that this > >> can be demoted to a warning, possibly with an option, is not in line w= ith my > >> expectation of how the GNU assembler should work and has traditionally > >> worked. > >> > > > > It is a hardware limitation. Once an incorrect command occurs, it will = be difficult to locate. This is a critical issue and should be reported as = an error, especially with the addition of APX our prefixes are becoming mor= e complex and diverse, it's time to make a change. > > I find this (including H.J.'s) position odd: Until me introducing the > warning, no-one cared at all. Presumably because, as indicated before, > Intel ISA extensions weren't really affected. Now suddenly everyone's > calling for an even stronger diagnostic. IOW if there is a concern now, > the same concern should have been there many years earlier. > Before APX, this isn't a concern since GCC won't generate such long instructions. After we got reports from people using APX GCC on real applications, it raised the alarm and changed my opinion. --=20 H.J.