[PATCH] x86: Warn .insn instruction with length > 15 bytes

[H.J. Lu]

On Tue, Feb 6, 2024 at 11:51 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 06.02.2024 19:06, H.J. Lu wrote:
> > On Tue, Feb 6, 2024 at 9:05 AM Jan Beulich <jbeulich@suse.com> 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.

-- 
H.J.