From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 598C93858C78 for ; Thu, 8 Feb 2024 06:26:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 598C93858C78 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 598C93858C78 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::330 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707373615; cv=none; b=chVERH1rMkRvPfR/qJkBJBd+pEGb4fbFg9DmNmwY0R2iTlXRBRalALrC0zwkp+Qx90K7ZurFRVCsSQ1Ti7HlnYn2r6fTOPKoFMebS1lZJ8+VRKwt5yTIKZ6lXX00RvVDopMj5qZ8+bJS/28khllQ5IDOxAyXqMKSi7/c2FSPS9Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707373615; c=relaxed/simple; bh=vx3Wb1cKrBJbEOHi0HdN2+xD+TgKqVGYqWUZdRyr4To=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Z02M7mGid4zBlKhDpwQqiTWWFl9CD5NzO4nwlnhyGkRQEpb5YS9uADjjf8GY3qmYy+wzb+pdRlPuPxfA9O3LPdaO3V3CD3MafU2tmyddzwk0GEra1NaucbtPwcz9uG/kOBCUigXOLwyEB1jIEmFxh7bUmCdp097N7ZsO8Wn3g2E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4102a186cfbso5604995e9.2 for ; Wed, 07 Feb 2024 22:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707373604; x=1707978404; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xbKBWrjVjlz1zZ/HqU3VxDg0W6u3PCavf57RXZZ22yw=; b=hQ9FoA7WFGCWQ6JWP/HlWD0XWrVKOEVhQyT6gMUozZr1JLSB6ksTup/dY3GWygTE6q G+eHgvmAWP9fmhi0L7eFAW09tZdGhmbBPeeECLlJjzDgHpY6vGLWIL/sCRmngncJ/A84 nUoHDwkmzrfQs5BUBU2UztTCaIi7TfDZWX8tswvCDZxcd+aTk5nicfEyjqMX+sN5k1JT wUy3++KaMi2kJNGKq3KVVmGdH50GHKl3iSu24F2VEVWq/vrADwiXVezuL2IPKZbT3jed Qz/EO7hH8WYNXtN5jkhf2B7fWXCshycvIKaseXVZgRm6ZKyia9O+dkqeAnf9vYsV1PTw FdEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707373604; x=1707978404; h=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=xbKBWrjVjlz1zZ/HqU3VxDg0W6u3PCavf57RXZZ22yw=; b=aJtv+qYaBauX7SWbHWSlIRz6WRulSNuKvkQoMPbibIw2fE06VJx1aSPPiNkbmBdkzK dCtECimXiDu0+Z53CHt2RS8JMEb1NJcg9jNm0z9aZTtGXriPDmsSz3PC5GQ5FX0KzSQH CVz9eUbsl9wk6G/L0YTjgm4y4wfjcoVE4Pco1JCEaJcWxeJH1ykaSGUgquwtbOehX8wG OMeH2+AQizsfgX7GLEkQUiMjn3XZ4i8E5CiPWJwqwTTgFR1TirJOl131/zozj279b+pE zQJ3Z348Xaemmm+/9Lwez8bmyAbqsq8YmuJy2CQFs/qtE/nJ94H/lNVlFpvM7yGvcQxE zmxw== X-Gm-Message-State: AOJu0YwqJxMVxhYmS7xOxd5foukLymwLFzK2SUPQO1+RPq/FK3KfIWFg Vciq9BJkPbO/CvRzaXv5YWgCihPYJcNPcUcWo9UlyWScBImVnpA+607vDwOV3y9zaM9UaKFVcEK kz/+QM2TM3kZfoYVCvFvVxl+zfww= X-Google-Smtp-Source: AGHT+IFClX00NVb7xEkLLYszRcOwxc71A0a340DcjwsDbBRednnXdYX1DadMFz1OhEx6g0OphQmFB3qa8UGoo9+DLkM= X-Received: by 2002:a05:600c:4691:b0:40f:d84c:ac68 with SMTP id p17-20020a05600c469100b0040fd84cac68mr6044473wmo.11.1707373604008; Wed, 07 Feb 2024 22:26:44 -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> In-Reply-To: From: Sunil Pandey Date: Wed, 7 Feb 2024 22:26:07 -0800 Message-ID: Subject: Re: [PATCH] x86: Warn .insn instruction with length > 15 bytes To: "H.J. Lu" Cc: Michael Matz , Jan Beulich , binutils@sourceware.org Content-Type: multipart/alternative; boundary="0000000000002a75160610d8e54d" X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000002a75160610d8e54d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 6, 2024 at 8:30=E2=80=AFAM H.J. Lu wrote: > On Tue, Feb 6, 2024 at 7:48=E2=80=AFAM Michael Matz wrote: > > > > Hello, > > > > On Tue, 6 Feb 2024, H.J. Lu wrote: > > > > > > > > > It is an error on both Intel and AMD processors. There is no > > > > > > > valid reason not to be an error at the moment. > > > > > > > > > > > > Jan gave you one. I would prefer for the assembler to not be > anally > > > > > > > > > > That is not a valid reason. > > > > > > > > Yes it is. > > > > > > > > > There is no such processor in the foreseeable future. > > > > > > > > Doesn't matter. > > > > > > > > > > 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 for > > 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 > > instruction 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 sequence correspending to the overlong instruction is > > not "useless". > > With as_bad, assembler will continue to assemble, just not generate > an object file. We ran into this with APX. Not everyone checks > assembler warnings closely. It led to mysterious crashes. I am > not against it if someone else implements an assembler option to > turn this error into a warning. > > IMO, most people check error at first glance not warning. Making it error by default with proper error message will save precious debugging time for assembler users, especially if it can avoid mysterious crashes down the road. --0000000000002a75160610d8e54d--