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

[H.J. Lu]

On Thu, Feb 8, 2024 at 12:18 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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 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".
> >>
> >> I understand why you want to give an error by default, even though I disagree
> >> with even that (in my book only a warning is justified).  But ruling out that this
> >> can be demoted to a warning, possibly with an option, is not in line with 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 more 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.

-- 
H.J.