[PATCH] x86: Warn .insn instruction with length > 15 bytes
Cui, Lili
lili.cui@intel.com
Thu Feb 8 06:41:51 GMT 2024
> > 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.
Thx,
Lili.
More information about the Binutils
mailing list