From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by sourceware.org (Postfix) with ESMTPS id 3A5B23858408 for ; Wed, 7 Feb 2024 15:24:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3A5B23858408 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 3A5B23858408 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::b29 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707319479; cv=none; b=hfHQ1KbkhESCTge4/Oo5DBWE4Sq9CHSd9CsMkguzX6Nk5ndThjrMMzU7FtUoe81oMZbwgbLN7PFRFgj6hRH3ozYybBD52NAiAEnT/2FIcH3iSFSIusgcBFBXIbVCs45sz0HOj0OkYnoceG2mTp7T4DMRzIESUrElmebTDj3U+F8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707319479; c=relaxed/simple; bh=YKxwvdGZTaNeZk5Y2hHTiS/Zg21VCpzgd5Qe1newFCU=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=hQ6zCnrmvcTWPx/zvFl8V/RNu5XsVjqkZ/c6akmncDWukBjemmXHwSpag/ajbVyXdBnD1vTpIXq6iJIK8B2E6in5Oyp9d/hLl3w9HUk0Rm/iMr/nCUmwuPobkNHoTiPhibwE6LOeqZS51Ch6TZQEQp+/8meOT9X6kXgqa0V2EvY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-dc6e4a55a71so699521276.3 for ; Wed, 07 Feb 2024 07:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707319476; x=1707924276; 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=MMMcQCt/1h0CNHy3NzywExKr4TXv855HwOBUkGkFaLk=; b=S7IUuwdF3RYUEljcT+CEmCr7yzJcVOy07aNAZCsvYwO0yv0yg1pcE/S5ASVy7hKfzL 2z8ECstOC1/rLB9L8n7ciDirfaa/9FbVVfyNojnFgID0/UbUir6AY9BxIq39WG3ktCXN u0JFKLXnN5DPkj3hjjgdaCsYl8LmOUnj64Vwme1NLhRDrVluFpGNSuO9Ze5awzxQXtAr Q7oSmAOKrKSp3jikhnDBeutLIBSO9lXsBSHIqj8gYk6luCZvfAN/h8iHx/GG3l0DDQrk mMZ+73X8F0vwmMOsvLIE3TNnlf27wENQc4Cel4jw1231Y1BiyGDTWKsYB70kqn0EG/3l 8fOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707319476; x=1707924276; 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=MMMcQCt/1h0CNHy3NzywExKr4TXv855HwOBUkGkFaLk=; b=cd7fe2tdSe2LhQ25oaDXWWmeX1VQQdGg0jwmC4Mjb0AkPwHgrHIaP6XK6rI1KjdVI/ ktf7azv4wKQJMIJGI9lCcIt2SpnedE/mZ9ETzCClFfssDqZ20uzfSNgzv75T94Y4tnl7 Mnf31DUjANY2HFrNJYhuX7DHyWEEFK+dPb2ZyV5SlmV/iaRs/0TIYdAFMk0LUtqYdFAX bLhrS30qP4J/9wmg/q8D/gU8VGa83vCFCG7ZIE83bSQXYiRab/8/GYLy8wnBGAc3lsI5 8JrFSgcnWFLtIz+u+M1ulionHQrJMS2ojCrPR3p+g+qhlIQYv5VkrCVG/WbD2WJGF5lC CWoQ== X-Gm-Message-State: AOJu0YxIKue6kKuhOnBIgm8NvL72wSu5ZEn/HqSnvCcEGJnujwAYqcd2 Wo+HHiDcuKEn3tlo1LW3QcVHsudkx7ZpgtvSwBPDg6E5yXg5INuPlhGXS9j+cOrDdXVl2uFYrZh 9G8JV4ps50J5lqMZkDa7TTJ6qRzH2gE4M X-Google-Smtp-Source: AGHT+IHV1wKKXBHcZcYVtDvACaZqbCTp9zeR6K4mOZDHprfNy/X6cqQNXUSZwWKKotl4qKFBmL4Q4cpDly48RZQ2iSM= X-Received: by 2002:a25:acce:0:b0:dc2:349d:10cf with SMTP id x14-20020a25acce000000b00dc2349d10cfmr4908480ybd.53.1707319476435; Wed, 07 Feb 2024 07:24:36 -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> <2721d4bc-e29f-4ed1-8fac-064fe0711029@suse.com> In-Reply-To: <2721d4bc-e29f-4ed1-8fac-064fe0711029@suse.com> From: "H.J. Lu" Date: Wed, 7 Feb 2024 07:24:00 -0800 Message-ID: Subject: Re: [PATCH] x86: Warn .insn instruction with length > 15 bytes To: Jan Beulich Cc: binutils@sourceware.org, Michael Matz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3014.7 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 Tue, Feb 6, 2024 at 11:51=E2=80=AFPM Jan Beulich wro= te: > > On 06.02.2024 19:06, H.J. Lu wrote: > > On Tue, Feb 6, 2024 at 9:05=E2=80=AFAM Jan Beulich = wrote: > >> > >> On 06.02.2024 17:28, H.J. Lu wrote: > >>> 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. > >> > >> But it should be the other way around: The compiler could pass an > >> option to promote the (default) warning to an error. And if you > >> don#t pay attention to warning for assembly files, you could pass > >> the same option as well. Without harming anyone else with anything > > > > People who use/need instructions > 15 bytes belong to a very small > > minority. If they want to do it, they can use .insn or use binutlls 2.= 41 > > or older. The default assembler isn't for them. > > No, staying on an old assembler isn't viable. And minority or not, you > have to face it: In the present discussion it is you who represents a > minority. As such I'm even inclined to suggest that your earlier patch > wants reverting, on the basis that it was put in despite there being > disagreement. Unless you soon come forward with an incremental change > undoing at least the worst of its effects ... Please tell me exactly which projects are negatively impacted by disallowing > 15 byte instructions. > >> that has worked before. > > > > The reason that we didn't run into the size limit before is that normal > > instruction usages never exceed the 15 byte limit before APX. > > Didn't I earlier give examples of "normal instructions" that have this > issue? I don't see anything "not normal" in insns using e.g. segment or > address size overrides. > > The impression I'm getting is that the problem originally was of no > interest to you because initially it affected AMD-specific insns only. > And the subsequent appearance of the same issue in HLE insns then was > mentally put off by you for being "too exotic" (and I partly agree > that _there_ one may indeed consider the example contrived). You only > started caring when it was an Intel extension which was noticeably > affected. Yet that's not the position you ought to take as a binutils > maintainer, imo. > Assembler should generate decodable binaries for normal instructions even with a warning. --=20 H.J.