[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